Indonesia Quantum Computing and Security Forum · Technical Deep Dive

The Quantum Attack Surface
and How We Simulate It

HNDL, QKD attack modelling and quantum cryptanalysis — analysed in depth, then mapped onto three real platforms: Karsa Quantum OS, QryptOn, and Origin PilotOS. With full feature inventories, the Origin Quantum hardware estate, and the deployment architecture that ties them together.

qrypton.karsa-siber.com IQCSF on LinkedIn Origin PilotOS

Simulator-first · no production key or real QPU involved Evidence reviewed 3 September 2026 PT Karsa Sibernetik Internasional

How this brief is organised

Seven parts, one argument

The threat is analysed first and on its own terms. Only then do the three platforms appear — because a capability claim is only meaningful once you know exactly what it is being claimed against.

The attack surface

HNDL, Shor, Grover, the QKD implementation-attack family, and the adjacent failures that get missed. Nine slides of threat analysis before any product is mentioned.

Origin PilotOS

The quantum control plane in full: architecture, seven kernel modules, console, 15 APIs, message push, error codes, deployment — read from the v4.2 manual and the vendor's own pages.

Karsa Quantum OS

Twelve modules, feature by feature, read from the prototype source: state model, backend inventory, ZMQ contract coverage, the adapter, and the verification result.

QryptOn

The PQC service line: scanner invariants and scoring, the browser toolkit, and Qryptonite — the Rust library underneath both.

Correlation

Attack by attack: which layer simulates it, which layer mitigates it, and which layer must not claim it.

Deployment architecture

Zones, ports, processes and data flows — four topologies from a single laptop to a sovereign installation.

Roadmap, status, sources

What is built, what is next, and every claim traced to where it came from.

The shape of the system

Three systems, three jobs, one seam

Each of these exists today and each works standalone. What makes them interesting together is that they occupy three different layers of the same problem — and none of them can substitute for another.

Layer 3 · Cryptography

QryptOn

Post-quantum cryptography that actually protects traffic. Readiness scanner, browser toolkit, and Qryptonite — a pure-Rust FIPS 203/204/205 implementation. Runs entirely on classical hardware; that is the point.

risk
signal

Layer 2 · Security semantics

Karsa Quantum OS

Ten-module control-plane platform plus the security engines Karsa builds on top: exposure modelling, migration optimisation, benchmark orchestration, and the planned HNDL and QKD labs. Owns the adapter that joins everything below it.

canonical
jobs

Layer 1 · Execution

Origin PilotOS

The quantum operating system. Multi-backend access, scheduling, hybrid task lifecycle, compilation, resource management, monitoring. Drives Origin Wukong hardware and a Python simulator equally well.

The boundary that matters: PilotOS orchestrates quantum computation. It does not implement cryptographic protection, and it ships no BB84 engine, no HNDL model, and no PQC runtime. Every security semantic in this brief is something Karsa or QryptOn supplies. Confusing the two is the single most common error in quantum-security marketing.

Part 01 of 07

The attack surface

Four attack families, analysed on their own terms — before any platform is proposed as an answer.

01 Threat · master map

Every quantum-relevant attack, and what it actually needs

Not one threat but a family, and the members have wildly different prerequisites. The right-hand column is the one people skip — and it is where most of the confusion lives.

Attack	Class	What it defeats	Adversary prerequisite	Realistic today?
Harvest-now-decrypt-later	Strategic	Confidentiality of anything recorded now under RSA/ECDH key exchange	Storage, patience, network access. No quantum computer at harvest time	Underway now
Shor — integer factoring	Cryptanalytic	RSA at every key size; no larger modulus helps	Fault-tolerant QC, ~10⁵–10⁶ physical qubits under current estimates	Not yet
Shor — discrete log (ECDLP)	Cryptanalytic	ECDH, ECDSA, EdDSA, DH, DSA — and every major blockchain	~100× fewer Toffoli gates than RSA; minutes, not days, once running	Not yet — but cheaper than RSA
Grover — unstructured search	Cryptanalytic	Symmetric keys and hashes — quadratically, not catastrophically	Enormous coherent runtime; parallelises poorly	Manageable — use 256-bit
QKD implementation attacks	Physical	Deployed QKD links, via detectors, sources and side channels	Optical access to a real QKD fibre. No quantum computer at all	Demonstrated in labs
Downgrade / hybrid stripping	Protocol	A PQC rollout that still negotiates classical-only as fallback	Ordinary active MITM position	Available today
Trust-anchor & signature forgery	Cryptanalytic	PKI roots, code signing, firmware — forward in time only	CRQC at the moment of verification, not of signing	Not yet
Crypto-agility failure	Organisational	Your ability to respond at all when any of the above lands	None — this one is self-inflicted	Already the default

01 Threat · algorithm primitives

Shor breaks. Grover only weakens.

Two algorithms, two entirely different consequences. Treating them as one threat produces the wrong remediation plan — usually an expensive symmetric-key project that was never needed.

Primitive	Quantum attack	Effect	Fix
RSA (any size)	Shor	Broken	ML-KEM / ML-DSA
DH · DSA	Shor	Broken	ML-KEM
ECDH · ECDSA · EdDSA	Shor	Broken	ML-KEM / ML-DSA
AES-128	Grover	~64-bit	Move to AES-256
AES-256	Grover	Adequate	No change
SHA-256 / SHA3-256	Grover	Adequate	No change
ML-KEM · ML-DSA · SLH-DSA	None known	By design	Deploy

Why key size cannot save RSA

Shor solves factoring and discrete log in polynomial time. RSA, DH and every elliptic-curve scheme rest on exactly one of those problems being hard. There is no modulus large enough — the hardness assumption itself is gone, which is why the answer has to be different mathematics.

Why Grover is survivable

Grover gives a quadratic speedup, so 256-bit symmetric keys retain roughly 128 bits of quantum security. It also parallelises badly: running it across many machines buys far less than intuition suggests, and the coherent runtime required is punishing. Doubling symmetric key length is a genuinely sufficient response.

The asymmetry that drives everything downstream: a recorded key exchange can be attacked years later; a signature that already verified cannot be retroactively forged. That single fact determines migration order, and it is why QryptOn's scanner scores key exchange out of 100 and reports signature availability at weight zero.

01 Threat · attack A

Harvest now, decrypt later: the anatomy

The only attack in this brief whose first stage requires no quantum technology whatsoever. It is a storage-and-patience problem, which is exactly why it is already happening.

Stage 01 · today

Capture

Passive collection at a transit point, cable landing, cloud tenancy or compromised midpoint. TLS and VPN sessions, database replication streams, backup transfers.

→

Stage 02 · today

Index & select

Ciphertext is cheap to store but expensive to break, so the adversary triages: which sessions carry long-life value, which used RSA or ECDH, which endpoints they belong to.

→

Stage 03 · Q-day

Recover keys

A CRQC runs Shor against the recorded key-exchange material. The session key falls out; the symmetric layer underneath was never the obstacle.

→

Stage 04 · after

Decrypt & exploit

Plaintext from years earlier. Value depends entirely on how long the content had to stay secret — which is a business property, not a technical one.

Why this changes the deadline: for every other attack, you are safe until the capability exists. For HNDL you are exposed from the moment the traffic leaves the building. Migration must complete before the capability arrives, not begin then — and for data captured yesterday, it is already too late to help.

Who says so: CISA, NSA and NIST used precisely this scenario in their August 2023 joint quantum-readiness fact sheet to justify starting inventory and roadmap work immediately, years ahead of any credible CRQC. It is the standard official justification for acting early.

01 Threat · attack A · quantifying it

Two ways to write the same inequality

Mosca's inequality is the standard formulation. The Karsa exposure window is the same arithmetic rearranged to produce a number a steering committee can act on. Both are planning heuristics — neither predicts a date.

Mosca's inequality — the test

X + Y > Z

X — years the data must stay secret
Y — years the migration takes, start to finish
Z — years until a capable quantum computer exists

If the inequality holds, you are already exposed. It answers yes or no.

Karsa exposure window — the priority

W = Z − Y − X

W < 0 — CRITICAL, exposure already closed
0 ≤ W < 3 — HIGH · 3 ≤ W < 7 — MEDIUM · W ≥ 7 — LOW

Same inputs, but it returns a signed magnitude, so thousands of assets can be ranked against each other rather than each answering yes.

10yr

Confidentiality lifetime required (X)

4yr

Migration lead time (Y)

12yr

Assumed threat horizon (Z)

−2yr

Exposure window — CRITICAL

Modelling honesty: these are the Quantum Exposure Simulator's own default values, applied to Mobile Banking API — ECDH/ECDSA, risk score 90 in the Migration Optimizer's asset list. Neither formula is a NIST or CISA standardised metric. They exist to rank and compare, not to forecast Q-day.

01 Threat · attack A · what is actually at risk

HNDL urgency is set by the data, not the system

The same TLS stack protecting a session token and a genomic record carries completely different HNDL risk. Prioritisation has to start from the confidentiality lifetime of the content.

Data class	Secrecy lifetime	HNDL urgency	Typical carrier
Health & genomic records	Decades to lifetime	Critical	TLS, HL7/FHIR, backup
State & diplomatic traffic	Decades	Critical	VPN, IPsec, satcom
Identity & biometric enrolment	Lifetime — cannot be reissued	Critical	TLS, enrolment API
Long-lived trade secrets, IP	10–30 years	High	File transfer, email
Financial records	7–10 years	Medium	TLS, SWIFT, core banking
Legal & contractual archives	7–20 years	Medium	Document store, S/MIME
Routine session traffic	Minutes to days	Low	TLS

Forward secrecy does not save you

Ephemeral ECDH is the standard answer to key compromise, and against a classical adversary it works. Against a quantum one it does not: the ephemeral public values were transmitted in the clear and recorded along with everything else. The discrete-log problem underneath them is exactly what Shor solves. Perfect forward secrecy protects against a stolen long-term key, not against a broken hardness assumption.

Where Indonesian institutions concentrate risk

Population-scale identity, health and civil-registry data have the longest secrecy lifetimes of anything an organisation holds, and biometric enrolment cannot be rotated after a breach. Combined with financial infrastructure under 7–10 year retention obligations, the national HNDL exposure sits in the top two rows of this table, not the bottom.

01 Threat · attack B · the moving target

The cost of breaking RSA-2048 keeps collapsing

The hardware did not get better this fast. The algorithms and error-correcting codes did. Every reduction below came from compilation, arithmetic and code design — not from a bigger machine.

~10⁸–10⁹

2012 · Fowler et al.
Hundreds of millions to a billion physical qubits

~20 M

2019 · Gidney & Ekerå
20 million qubits, ~8 hours

< 1 M

May 2025 · Gidney
Under one million noisy qubits, under one week

< 100 k

Feb 2026 · Iceberg Quantum
Pinnacle qLDPC architecture, simulation only

What produced the 2025 drop

Approximate residue arithmetic (Chevignard, Fouque & Schrottenloher 2024) — far fewer logical qubits
Yoked surface codes — roughly triple the storage density for idle logical qubits
Magic state cultivation — high-fidelity resource states at close to ordinary gate cost
Toffoli count cut by more than 100× against the prior approach, to roughly 6.5×10⁹

Read the trend, not the number. Gidney himself states he sees no further order-of-magnitude reduction without changing the physical assumptions — and Iceberg's answer was to change them, moving from surface codes to qLDPC. Each reduction shifts difficulty onto harder engineering: non-local connectivity, real-time qLDPC decoding, month-scale fault-tolerant stability. The qubits get fewer; the machine gets nastier.

Why a planning deck must track this

An exposure model is only as good as its Z. Three papers in under twelve months moved the resource estimate by two orders of magnitude, and every one of them shortened the plausible horizon. A risk engine that hard-codes a threat-horizon constant is wrong within a year.

This is the single strongest argument for building the exposure model as a parameterised batch simulation rather than a spreadsheet: when Z moves, you re-run thousands of assets against the new assumption in one job instead of re-deriving a plan.

Correction to our earlier deck: the previous IQCSF slide cited Gidney & Ekerå 2019 — ~20 million qubits, ~8 hours — as the scale reference. That figure is now two generations out of date and is superseded here.

01 Threat · attack B · the sharper edge

Elliptic curve falls first, and falls faster

Almost every quantum-threat briefing is written about RSA. The elliptic-curve case is substantially cheaper to attack and arrives with an operational twist that RSA does not have.

Dimension	RSA-2048	ECDLP-256
Toffoli gates	~6.5 × 10⁹	~70–90 × 10⁶ (≈100× fewer)
Physical qubits	< 1 M (2025) · < 100 k (2026 arch.)	< 500 k (Google, Mar 2026)
Runtime once running	Under a week	Minutes
Precomputation	Limited	Primeable — half the work depends only on curve parameters
Time after key exposure	n/a	≈ 9 minutes to recover a private key
Prior best estimate	20 M (2019)	~9 M photonic (Litinski 2023) — ≈20× reduction

The blockchain corollary

Bitcoin's average block time is ten minutes. Once a public key is revealed in an unconfirmed transaction, a primed attacker needs roughly nine. Google's own estimate puts the probability of deriving the private key before confirmation at around 41% under idealised conditions. The mitigations are protocol-level: stop reusing addresses, avoid unnecessary public-key exposure, private mempools, and quantum-resistant signature schemes.

Responsible disclosure, in cryptanalysis. Google did not publish the attack circuits. It released a zero-knowledge proof — SP1 zkVM with a Groth16 SNARK — letting anyone verify the resource estimates without obtaining the circuits, and engaged the US government before publication. That an offensive quantum result now warrants disclosure discipline is itself a signal about where this field has moved.

Why this belongs in an HNDL model: ECDH is the dominant key exchange on the modern internet. If ECDLP is cheaper than factoring, the recorded-traffic problem is worse than an RSA-only analysis suggests, and any asset inventory that scores "ECDH" as equivalent to "RSA" is understating its own exposure.

01 Threat · attack C · the idealised protocol

QKD in theory: eavesdropping leaves a mark

An illustrative BB84 walkthrough under idealised assumptions. Measuring in the wrong basis disturbs the state, and that disturbance shows up as error rate on a publicly compared sample.

Clean channel

> 2048 pulses sent · basis sifting → 1024 raw bits

> Public QBER sample (200 bits): 2.1% error

> Below the ~11% threshold — key accepted

> Error correction → information reconciliation

> Privacy amplification → ~750-bit secure key

Intercept–resend by Eve

> 2048 pulses sent · Eve measures and re-emits

> Public QBER sample (200 bits): 24.6% error

> Exceeds the ~11% threshold — protocol aborts

> Key discarded, no secret material derived

> Eavesdropping detected, not prevented

What the protocol actually promises: not that eavesdropping is impossible, but that it is detectable — and that a compromised key is discarded rather than used. QKD is a key-agreement mechanism with an integrity alarm, not a shield.

Three caveats on the 11% figure: it is an illustrative asymptotic threshold under specific assumptions. Real deployments depend on finite-key analysis, on the specific protocol, and on hardware behaviour. Quoting one universal QBER threshold across all implementations is a claim we explicitly avoid.

01 Threat · attack C · where QKD is actually attacked

Nobody attacks the mathematics. They attack the optics.

The security proof holds within its assumptions. Real hardware violates those assumptions, and this is the family of attacks that has actually been demonstrated — none of which needs a quantum computer.

Attack	Target	Mechanism	Countermeasure
Photon-number splitting	Source	Attenuated laser pulses occasionally contain multiple photons; Eve siphons one and keeps it, learning key bits without adding error	Decoy-state protocol; SARG04; true single-photon sources
Detector blinding / faked state	Detector	Bright light forces avalanche photodiodes into linear mode; Eve then drives detection events at will and can recover the full key undetected by error checking	Optical power monitoring, detector self-testing, MDI-QKD
Trojan horse	Source & receiver	Eve injects light into Alice's or Bob's apparatus and reads the back-reflection to learn the encoding settings	Optical isolators, passive optical components, watchdog detectors
Time-shift	Detector	Exploits efficiency mismatch between the two single-photon detectors across the detection window	Active basis selection, temporal monitoring, MDI-QKD
Phase remapping / non-randomisation	Source	Imperfect or absent global phase randomisation lets Eve remap the encoded states	Active phase randomisation, characterisation in the proof
Dead-time	Detector	Detector recovery periods leak basis information through detection timing	Simultaneous dead-time enforcement, MDI-QKD
Electromagnetic side channel	Electronics	RNGs, detectors and high-speed electronics radiate signals correlated with internal state — basis settings, detection events	Shielding, TEMPEST-grade engineering, emissions testing
Denial of service	Channel	Cutting or degrading the fibre stops key agreement entirely — the abort behaviour is itself the vulnerability	Path diversity, fallback to authenticated PQC key establishment

The strategic point for a simulator: these attacks are the reason a QKD lab is worth building. Modelling BB84 with a perfect source and perfect detectors reproduces the textbook and teaches nothing. Modelling multi-photon emission, detector efficiency mismatch, dark counts and channel loss is where the interesting questions live — and it is all classical Monte Carlo.

01 Threat · attack C · the boundary

What QKD is for, and what it is not for

QKD is a legitimate technology with a narrow, real use case. Most of the harm in this space comes from claims made on its behalf rather than from the technology itself.

Defensible positions

Key agreement over a dedicated optical link between two trusted, physically controlled endpoints
Detection of certain eavesdropping classes, under stated assumptions
A useful defence-in-depth layer alongside PQC on very high-value, fixed, short-haul links
A research and training platform where protocol behaviour is the subject

Claims to refuse

"Unconditionally secure" without qualifying the implementation and proof assumptions
"QKD implemented in software" offered as a production security control
A universal ~11% QBER threshold applied to every protocol and deployment
Authentication solved by QKD — the classical channel still needs authentication, and that authentication needs PQC
Photonic-compute compatibility implying QKD hardware compatibility

What real QKD requires

A photon source, single-photon detectors, dedicated fibre or free-space optics, timing and calibration infrastructure, trusted-node design over distance, and an authenticated classical channel. NSA notes it needs special-purpose equipment and dedicated physical-layer communications.

Why it does not replace PQC

It secures a point-to-point link between fixed endpoints. It does not secure code signing, data at rest, stored backups, mobile clients, third-party APIs, or any of the several thousand places an enterprise uses public-key cryptography today.

Why it still belongs in the lab

Indonesian operators are already discussing quantum-safe networks and data centres. Being able to model a QKD link's behaviour, its failure modes and its economics — before anyone procures optics — is worth considerably more than the optics.

01 Threat · attack D · the ones that get missed

Four failures that need no quantum computer at all

These are the attacks a PQC programme creates for itself. They are available today, against organisations that have already started migrating — which makes them more urgent than Shor, not less.

Downgrade and hybrid stripping

A rollout that negotiates ML-KEM when both sides support it, and silently falls back to classical-only when they do not, gives an active attacker a switch. The fallback path is the real security level of the deployment, and an HNDL adversary only needs the session to take it once.

Test for it: does a hybrid handshake fail closed, or fall back quietly? A negotiated-evidence scan — not a declared-capability scan — is the only way to know.

Trust anchors and code signing

Signatures are not HNDL-exposed, but roots are long-lived. A federal or national root CA signing with RSA or ECDSA must be re-keyed to a PQC algorithm before deprecation — and re-keying a root means reissuing the entire subordinate hierarchy and redistributing trust anchors.

The long pole: firmware and code signing under SP 800-208 LMS/XMSS, on devices with 10–20 year field lives that may never be updatable again.

Crypto-agility failure

Most systems cannot change algorithm without changing code. That is survivable once. It is not survivable across FIPS 203/204/205 now, FIPS 206 later, HQC as a code-based backup, and whatever follows a lattice cryptanalysis result. Hard-coded primitives convert every future standard into a re-engineering project.

Design rule: algorithm identity belongs in configuration and in the inventory, never in the source.

Inventory drift

An inventory is a photograph, and dependencies reintroduce classical-only cryptography continuously — a new SDK, a vendored library, a bundled OpenSSL three minor versions behind. Organisations that completed a migration in one system routinely find it undone by the next release.

Design rule: the scan is not a project deliverable, it is a pipeline check with a failure threshold.

01 Threat · the deadline is now external

The clock is no longer a risk argument. It is a date.

Migration is expensive and the threat is not yet visible, which historically made it easy to defer. Standards bodies removed that option by setting one deadline for everyone at once.

Authority	Instrument	What it requires	Date
NIST	FIPS 203 · 204 · 205 — ML-KEM, ML-DSA, SLH-DSA	The finalised foundational PQC standards	Finalised 13 Aug 2024
NIST	IR 8547 (initial public draft)	RSA, ECDSA, ECDH, DH deprecated, then disallowed	Deprecated after 2030, disallowed after 2035
NIST	FIPS 206 (FN-DSA) · HQC	Falcon-based signature; code-based backup KEM	FIPS 206 not yet drafted as of mid-2026; HQC selected Mar 2025, expected 2027
NSA	CNSA 2.0	ML-KEM-1024 and ML-DSA-87 specifically — stricter than the common hybrid group	New NSS quantum-safe by Jan 2027
EU	Coordinated implementation roadmap (NIS CG)	National roadmaps, then high-risk migration, then completion	Roadmaps end-2026 · high-risk 2030 · complete 2035
Canada	ITSM.40.001	Departmental migration plans and phased completion	Plan Apr 2026 · high-priority 2031 · rest 2035
Indonesia	BSSN National PQC Migration Task Force	Cryptographic inventory, risk analysis, prioritisation, migration roadmap, execution, monitoring — with a draft Presidential Regulation on the PQC roadmap as an output	Kick-off 25 June 2026, BSSN Bojongsari

Update to our previous position. Our earlier QryptOn deck stated plainly that we could find no publicly available Indonesian PQC-specific guidance to cite. That gap has now closed. A national task force exists, chaired by BSSN, working toward a Presidential Regulation; the Kemenko Polkam / BSSN / Telkom forum of August 2026 added a proposed National Quantum Center and priority mapping of high-confidentiality data. The framework BSSN describes — inventory, risk, prioritise, plan, execute, monitor — is precisely the pipeline the next sections of this brief implement.

Part 02 of 07

Origin PilotOS

The quantum operating system underneath everything else — read from the v4.2 manual, then checked against the vendor's own current pages.

02 PilotOS · what it drives

Origin Quantum's machines, and China's 2026 landscape

PilotOS is not an abstraction exercise. It is the operating system shipped on real superconducting hardware, and the estate it addresses changed substantially in May 2026.

System	Route	Specification	Status & significance
Origin Wukong-180	Superconducting	180 computational qubits on a single core, plus 251 coupling qubits. T1 ≈ 40 µs, T2-echo ≈ 20 µs	4th generation, online 9 May 2026, accepting global tasks
Origin Wukong	Superconducting	72 computational qubits (198 total incl. 126 couplers) — the "Wukong chip"	3rd generation, online 6 Jan 2024. ~50 M remote accesses, 160+ countries, 900,000+ tasks completed
Hanyuan-2	Neutral atom	200 rubidium qubits, dual-core (100 × Rb-85, 100 × Rb-87), cabinet-scale, under 7 kW	CAS Cold Atom Technology, May 2026. Room-temperature enclosure; atoms laser-cooled to µK
Jiuzhang 4.0	Photonic	Up to 3,050 photons detected across 8,176 interferometric modes, 1,024 squeezed-state inputs	USTC, Nature, May 2026. First fully programmable photonic prototype at scale

99.9%

Single-qubit gate fidelity, Wukong-180 (typ.)

99%

Two-qubit gate fidelity (typ.)

99%

Readout fidelity (typ.)

Why the hardware slide belongs in a security brief: these are NISQ machines and none of them threatens a production key. But they are the substrate a control plane must manage, and they set the realistic ceiling on what a "quantum cryptanalysis demonstration" can honestly claim. 180 noisy qubits and <100,000 fault-tolerant qubits are separated by more than three orders of magnitude and an unsolved error-correction problem.

02 PilotOS · what it is

Origin Pilot — 本源司南 — China's first quantum OS

Launched 2021, open-sourced and made publicly downloadable in 2026. It sits between quantum hardware below and cloud, applications and supercomputing above, and it is the operations and scheduling hub of the Wukong machines.

Attribute	Value
Product name	Origin Pilot / Origin Sīnán (本源司南) · PilotOS
Manual reviewed	Origin PilotOS 4.2, User Manual and API Reference, v3.4, 29 April 2026
Vendor	Origin Quantum Computing Technology (Hefei) Co., Ltd.
Editions	Community Edition and Enterprise Edition
Backends addressed	Superconducting, trapped ion, semiconductor, neutral atom, photonic — plus classical HPC clusters
Programming framework	QPanda / PyQPanda, with QPanda3 Runtime; VQNet, ChemiQ, QCFD, pyqpanda-algorithm
Persistence	MySQL 8.0+ for structured metadata, MongoDB 6.0+ for circuits and raw results
Console	Browser, `http://<server>:10020`

Stated design goal

Highly efficient quantum-classical hybrid computing. The manual frames the problem as managing resources at large qubit scale, scheduling tasks efficiently, and achieving heterogeneous multi-backend and hybrid computation — the three things that stop a chip from being a service.

Intended audiences, per the manual

Quantum computing research teams
Quantum information scientists — including quantum cryptography, communication and networks
Quantum application developers
Technology companies and startups
National laboratories and policymakers

The second group is named explicitly. That is the doorway Karsa's security labs walk through — the manual anticipates cryptography users, it just does not serve them a protocol engine.

02 PilotOS · architecture §3.1

Six layers, from user code to cryostat

The manual's overall architecture diagram, read out in full. Each layer has a specific separation-of-concerns job, and the system-call interface between application and system layers is the enforcement point.

Application layer

User programming space — quantum-classical hybrid applications built on top of PilotOS.

Development kit layer

ChemiQ (computational chemistry) · QFinancial (quantum finance) · QCFD (computational fluid dynamics) · Quantum Heuristic Algorithm Toolkit · System Manager Interface

Programming framework

Quantum Programming Framework — high-level languages, simulation interfaces, circuit printing, equivalence checking, inversion, Qiskit/Cirq conversion · Quantum-Classical Hybrid Compilation Framework · QML Framework — autodiff, dynamic graphs, QPU/CPU/GPU backends, PyTorch and TensorFlow interop

System call interface

The unified gateway. Enforces isolation between system and application layers so user-space code reaches system resources only in a limited, controlled way.

Compute service layer

Quantum State Tomography (QST) · Expectation value estimation · Error mitigation (EM) · Distributed quantum circuit computing — decoupled from the kernel so business logic cannot destabilise core computation

System service layer

The kernel: system management, scheduling, compilation, resource management, backend service — communicating over secure internal channels

Compute backend layer

Superconducting QPUs · heterogeneous quantum chips · quantum simulators · high-performance classical cluster computing

Read this as an integration map. Karsa's security engines attach at two points only: above the system-call interface as applications, and beside the compute service layer as new domain services. Nothing Karsa builds needs to modify the kernel — which is what makes the architecture portable to a non-Origin backend later.

02 PilotOS · execution workflow §3.2

A task, end to end

Submission through result, as the manual describes it. This is the lifecycle every Karsa security job will inherit.

Submit

Via QPandaLite (Python SDK over the Nginx web interface), PilotOSMachine (Python and C++), or the Origin Cloud public HTTP API. All tasks land in QCloudServer.

→

Preprocess

Dedicated tasks — QST, expectation, EM — are routed to compute services for preprocessing before the kernel is invoked through system APIs.

→

Estimate

OSServerManager statically analyses the circuit: qubit count, depth, gate count, expected runtime. It decides whether resources exist to accept the task at all.

→

Schedule

The task enters the priority queue. FCFS or HRRN, selected in the configuration file, weighed against current backend availability.

Compile

Scheduled tasks are compiled to backend-native instructions through optimisation passes, with the pipeline selected by target modality.

→

Execute

BackendServer distributes to the target hardware over ZeroMQ, retrieves results and backend status.

→

Correct

Result-correction algorithms mitigate hardware noise; M3 sampling and correction matrices improve accuracy.

→

Persist

On completion the state moves to QCloudServer for storage and is dropped from OSServerManager, which retains only active tasks.

Tiered storage, by design: structured metadata — task ID, backend ID, timestamps — goes to MySQL for query and monitoring. Large unstructured payloads — full circuits, raw measurement results — go to MongoDB. The manual is explicit that this keeps the core system lightweight while preserving auditability, which matters when the payload is evidence for a security claim.

02 PilotOS · system service layer §3.3

Seven kernel modules, and what each one owns

Module	Role	Responsibilities as documented
QCloudServer	The only official gateway	HTTPS API surface. Unified access — no other direct path into the system is exposed. Request validation — identity, API permissions, parameters; malformed, unauthorised or malicious requests rejected before reaching core components. Persistent task management — user ID, submission timestamp, task type, configuration stored for full-lifecycle tracking, auditing and recovery. Secure internal routing and result delivery / state synchronisation.
ComputerServer	Middleware, kernel offload	Decouples common but less frequent computation from the core flow. Today: expectation value evaluation and full-circuit fidelity estimation. Four components — task preprocessing, subtask expansion, subtask execution, result aggregation (normalisation, weighting, statistical fusion). Explicitly designed for easy extension with new domain-specific capabilities.
OSServerManager	Central coordinator	Speaks to upper layers through SysCall. Task resource estimation — static circuit analysis for qubits, depth, gate count. Task queue management — tracks progress through the flow and pushes real-time status upward. Tiered persistence — MySQL for metadata, MongoDB for circuits and raw results.
ScheduleServer	Priority and dispatch	Max-heap priority queue; default policy HRRN (highest response ratio next). Initial priority set by OSServerManager from configurable policy — task type, user tier, business context — and explicitly not fixed at zero. Response ratio rises with wait time to prevent starvation. Each cycle: check heap top against available resources → dispatch or update all response ratios → refresh the queue.
QCompileServer	Circuit compilation	Hardware-agnostic development — submit QASM or internal IR, compiler adapts to target. Heterogeneous multi-backend — superconducting and ion trap pipelines selected dynamically. Parallel compilation acceleration — concurrent tasks, or one large circuit fragmented for parallel optimisation. Passes: multi-controlled gate decomposition, gate set conversion, circuit optimisation, qubit mapping and topology routing.
ResourceManager	Inventory of truth	Receives resource updates from backends and configuration commands from upper layers; maintains the live inventory of backend availability and qubit status; answers resource queries from other components.
BackendServer	Hardware communication hub	Manages heterogeneous backend units and handles task distribution and result receipt over a hybrid ZeroMQ messaging model — see next slide.

02 PilotOS · BackendServer §3.3.7

Two ZeroMQ patterns, chosen for two different jobs

This is the contract Karsa's simulator implements and the adapter terminates. Understanding why there are two patterns explains why a browser cannot talk to PilotOS directly.

Router–Dealer · request / reply

Characteristics: connection-oriented, bidirectional, synchronous request–response.

Distributing quantum computing tasks to specific backends
Receiving task execution results
Querying real-time task status
Retrieving randomized benchmarking (RB) experimental data
Heartbeat exchange for link health and fault detection

Why: ordered, reliable delivery — appropriate for critical control commands and result retrieval.

Pub–Sub · publish / subscribe

Characteristics: connectionless, unidirectional, asynchronous, event-driven. The backend service is the subscriber, listening for control-service broadcasts.

Proactive task status updates — abnormal termination, resource preemption
Dynamic chip parameter changes — T1/T2 coherence, gate fidelity
Automatic calibration completion notifications
Real-time chip resource availability — qubit failures, cooling recovery

Why: eliminates polling overhead and gives low-latency event propagation.

The consequence for any web platform: browsers cannot open ZeroMQ sockets. Neither pattern is reachable from JavaScript. Any browser-based console over PilotOS — including Karsa Quantum OS — requires a server-side adapter that terminates ZMQ and re-exposes the same contract over HTTP and a streaming transport. That is not an implementation shortcut; it is a structural property of the protocol, and it is why the adapter is a first-class component of the deployment architecture rather than a convenience.

02 PilotOS · visual management console §4

The console, feature by feature

Everything the manual documents in the visual management console — the surface Karsa Quantum OS mirrors and then extends.

Access & licensing

License verification — four states: not entered, valid, expiring soon, expired. Expired suspends all functions until a new licence is entered; remaining days shown in the main interface header
User registration — full name, organisation, unique account, password; duplicate accounts rejected; email server configuration required for multi-user registration
User login — account and password; default administrator admin / admin123
User management (admin only) — filter by email, Python API permission, role; toggle VIP, admin, and Python API access; reset password to default 123456; delete account

Dashboard

Resource usage — PilotOS service CPU and memory, host CPU and memory, refreshed periodically
Module status cards — per-module name, CPU, memory, and Normal / Abnormal service status derived from module CPU usage, with colour labels
Real-time task manager — running task ID, submission time, status

Upgrade module

Admin-only. Auto upgrade greyed out; manual upgrade recommended
Package placed in /opt/PilotOS-Upgrade (.tar.gz / .zip), directory scanned, multi-package selection sorted by version and build descending
Integrity and security verification, confirmation dialog, full-screen progress overlay, automatic reload

Resource management

Chip management — card per chip with live metrics; add, edit, delete custom chip resources; Pause Run / Resume Run to control scheduling directly from the card
Chip details · Information tab — interactive topology map (hover or click a qubit to locate it in the parameter table); qubit parameter table with frequency, T1, T2*, readout fidelity, single-qubit gate fidelity, high-frequency qubits auto-marked; chip properties covering logic gate timing, noise models and metadata; Push Config to Cloud and Download Config
Chip details · Configuration tab (admin only) — chip event notification settings with timed email alerts; exclusive machine time management with duration 60–3600 s and delayed execution
Cluster management — cluster name and status, master node IP, online/offline scheduling status, node/CPU counts and memory

Task management

Task submission — compute type (full amplitude, noise, partial amplitude, single amplitude, MPS, real chip); chip or cluster selection; measurement type, shots, target qubits, specified qubit block via topology dialog, mapping options, noise model; advanced settings for point label, priority, callback address; QProg via editor or .txt upload; historical task recall by Task ID repopulating parameters, QProg and results
My tasks — filter by compute type, backend type, time range, description; jump to details or to submission parameters
Task details — per-stage timestamp flow chart, submitter, error info, total and per-phase durations (compilation, queuing, measurement, post-processing), results
Real-time status — queued and executing tasks, auto-refresh control, total queue size, status code column
User task management — batch cancel (own tasks; admins all), set priority, queue count, account filter
Task report — time range, account, compute type and status filters; ~20 selectable columns including QST results and fidelity; CSV export

02 PilotOS · API reference §5

Fifteen documented APIs — the integration surface

Every endpoint in the manual. This is precisely what a Karsa adapter must wrap, normalise and make idempotent.

Endpoint	Purpose & key parameters
/management/pilotosmachinelogin	Authenticate with `apiKey`; returns `token` — prerequisite for everything else
/task/realQuantum/run	Submit to physical chip. `QProg`, `TaskType`, `ChipID`, `Priority`, `Configuration` (shot 10–20000, circuitOptimization, mappingFlag, specified_block, amendFlag, PointLabel). Must contain a measurement
/management/query/taskinfo	Query by `taskid` + `token`; returns state, circuit count, circuits, results
/system/queryBackendQueueTask	Backend queue: depth, task IDs, usernames, up to `maxQueryTaskSize`
/management/getchipconfig	Qubit params, noise model, CZ crosstalk compensation angles, available qubits — per `Label`
/task/run	Cluster simulation. `QMachineType` 0–4, per-type `Configuration`, `ClusterID`, `callbackAddr`
/task/query	Cluster simulation task status by `taskId`
/system/queryChipUpdateTime	Per-qubit calibration timestamps for a backend

Endpoint	Purpose & key parameters
/system/pauseChipSchedule	Pause or resume scheduling for a chip (`isPause`)
/system/queryChipScheduleState	Scheduling state for an array of chip IDs
/system/manualSampleM3	Trigger manual M3 sampling for a chip and point label
/session/apply	Open a session with `LifeTime` in minutes; returns `SessionId`
/session/append_task	Submit inside a session — same shape as chip submission plus `SessionId`. Grants higher priority
/session/release	Close the session; may report Task is running
/management/query/best_qubit_blocks	Optimal qubit blocks for a chip given `QubitNum` and `QubitBlockNum`
/task/query_task_priority	Current effective priority of a task

Session mechanism — worth noting for security work. A session is a time-boxed reservation that grants elevated priority to a group of tasks. For a batch HNDL sweep or a seeded QKD parameter study, this is the correct primitive: it keeps a reproducible experiment together, and it stops a thousand small Monte Carlo jobs from starving other tenants.

02 PilotOS · message push §6 · type definitions §7

Push topics, type enums and the error dictionary

Message push · 5 events

chip_calibration_start	Calibration qubits, couplers, CZ pairs, discriminators
calibration end	chipId, lastCalibrationTime, calibration bit and bit-pair lists
chip_update	New chip configuration JSON — qubit count, high-frequency qubits
chip_manual_maintenance_start	Maintenance window opened
chip_manual_maintenance_end	Maintenance window closed

Compute backend types

0	Full amplitude simulation
1	Noise simulation
2	Partial amplitude simulation
3	Single amplitude simulation
4	MPS simulation
5	Real chip computing

Task types · 11 values

−1	Unknown
0	Monte Carlo measurement
1	PMeasure
2	QST
3	QST density matrix
4	Fidelity calculation
5	Expectation calculation
8	Noise learning
9	Readout error mitigation
10	Quantum distributed computing
11	Fidelity measurement

Task status

0 / 1 / 2	Unknown · received · executing
3 / 4 / 5	Success · failed · queuing
35	Cancelled

Error codes · 44 defined

0–5	No error · database · OriginIR syntax · JSON parse · backend compute · queue full
6–12	Qubit count exceeded · unsupported backend · timing exceeded · task type · VM init · compilation · estimation
13–20	Metadata config · fidelity density matrix · QST program · empty program · qubit/gate mismatch · chip topology · chip task program · duplicate MEASURE
21–26	DB operation · status info full · backend send failure · cluster compute · topology cannot execute circuit · task config
27–35	Unknown app ID · unknown task ID · subtask result parse · syscall timeout · terminated · URL · parameter · circuit length · chip offline
36–43	Unknown · login password · username taken · token verification failed · task query · user query · insufficient permissions · API key
> 1400	Measurement and control error — marks a hardware fault

The bolded codes are the ones an adapter must map to retry-versus-fail semantics. Confusing 23 (transport) with 25 (circuit will never fit this topology) produces an infinite retry loop against a task that cannot succeed.

02 PilotOS · installation §2 · operations §8

Deploying it, and keeping it alive

Hardware baseline

CPU — AMD Zen 5, Intel Arrow Lake / Diamond Rapids or newer; minimum 4 cores, allocated to the VM if virtualised
Memory — ≥ 64 GB, DDR5 at ≥ 5600 MHz
Storage — hundreds of GB during operation; ≥ 1 TB reserved recommended
NIC — ≥ 10 Gbps, because quantum state space grows exponentially and the network must not become the bottleneck

Software prerequisites

Ubuntu Server 22.04 LTS recommended
Python ≥ 3.8.0
Docker ≥ 20.10.0 with docker-compose
MySQL ≥ 8.0 — must allow remote access
MongoDB ≥ 6.0 — must allow remote access

Deployment sequence

$ tar -zxf pilotos-x.x.tar.gz

$ sudo pip3 install -r requirements.txt

$ vim mysqlInit/config.yml

$ sudo python3 AutoDeploy.py initDB

$ sudo vim ./PilotOS-Config/config.json

$ sudo python3 AutoDeploy.py loadImage

$ sudo python3 AutoDeploy.py start

→ http://<server>:10020 · admin / admin123

Package contains AutoDeploy.py, docker-compose.yml, mysqlInit/, the pilotos:x.x.iso image, PilotOS-Config/, requirements.txt, Upgrade.py, Util.py
Startup verifies MySQL and MongoDB connectivity first and refuses to proceed if either fails
Stopping the container discards in-image modifications
Stop the upgrade daemon with sudo kill — never kill -9, which strands /var/run/autodeploy_upgrade.pid and blocks the next start

Documented failure modes

Task stuck in "Sent"	Measurement-and-control link down — check network, restart the control service
Database connection failed	Redis not running — `systemctl start redis`
Compilation failed	Circuit syntax error
Slow page load	Cache buildup, browser or server side
Licence service unavailable	IP misconfiguration (never 127.0.0.1 — the image is isolated), MySQL schema not initialised (expect 26 tables), or MongoDB auth/bind
Licence server unreachable	Local network cannot reach the public verification endpoint

Operational note for a sovereign deployment: licence activation requires outbound internet access to the vendor's verification endpoint, and an expired licence suspends all system functions. Any air-gapped or nationally isolated installation must resolve this with the vendor before design, not during commissioning.

02 PilotOS · capability envelope

Six core capabilities — and the four things it does not do

The vendor's own capability statement, set against the security functions it does not provide. Both halves matter: the left is what Karsa gets for free, the right is what Karsa must build.

Native · six documented capabilities

01 Unified multi-backend access — multiple physical modalities plus classical resources; high-efficiency communication, invocation and data channels; hybrid task submission, execution and result return
02 Multi-user, multi-task collaborative scheduling — concurrent queue management, joint quantum-classical orchestration, priority management and resource isolation including high-fidelity prioritisation
03 Unified hybrid task management — quantum, classical and quantum-supercomputing tasks in one lifecycle: submission, queuing, execution, retry; responds to system calls and user commands
04 Hybrid compilation orchestration — heterogeneous compilation, multi-level workflows, multi-node parallel compilation and batch processing
05 Unified resource management, monitoring and alerting — quotas and permissions, periodic fidelity checks, real-time status, anomaly detection and alerts
06 System-level noise correction — independent sampling allocation, correction-matrix acquisition, mitigation applied to sampling results

Quantum cloud computing services Quantum-supercomputing collaboration Turnkey machine delivery

Absent · must be supplied by Karsa or an external control

Capability	Owner	Why it is not native
QKD protocol engine	Karsa	Photonic compute backends are documented. No BB84/E91/B92 or decoy-state application exists. QKD is not a chip-compute task
HNDL risk model	Karsa	Entirely a classical business-risk calculation. Nothing in a quantum OS knows what a secrecy lifetime is
PQC runtime	Karsa / QryptOn	ML-KEM, ML-DSA and SLH-DSA run on classical CPUs. The control plane can schedule them; it does not implement them
Cryptographic inventory / CBOM	Karsa	Asset schema, scanners, attestation workflow and evidence lineage are business-layer concerns
Key protection	External	HSM, key vault and PKI stay outside the control plane. Private keys must never sit in the business database
Enterprise identity & approvals	Karsa	Console roles are tenant-local. SSO, RBAC across the estate, exceptions and sign-off are the adapter's job

Part 03 of 07

Karsa Quantum OS

Twelve modules, read feature by feature from the prototype source — plus the adapter that makes a browser able to talk to a quantum control plane at all.

03 Karsa Quantum OS · the surface

Twelve modules, six control plane, six security

A dependency-free static HTML, CSS and JavaScript application — no framework, no build step, no CDN, no backend required. It runs standalone from local state, and switches to live control-plane data the moment the Karsa adapter is reachable.

Platform · mirrors the control plane

Command Center

KPIs · event feed · module map

Task Management

MsgTask / TaskStatus lifecycle

Resource Management

chip inventory · M3 · qubit blocks

Status Monitoring

Router / Pub health · alerts

API Console

full ZMQ contract explorer

Access & License

roles · provisioning · licence

Use cases · Karsa-built security value

PQC Migration Optimizer

constraints → portfolio → waves

PQC Benchmark Lab

ML-KEM · ML-DSA · SLH-DSA

Quantum Exposure Simulator

single-asset urgency signal

HNDL Batch & Vault Lab

portfolio sweep · synthetic vault

QKD Security Lab

BB84-family Monte Carlo · Eve models

Integration Architecture

native / adapter / custom map

Prototype boundary, stated in the source README: this is an interactive simulation. It is not connected to a quantum processor, a live vendor API or a production key store, and no displayed post-quantum primitive protects real traffic. All metrics, queues, benchmark timings and optimisation outputs are modelled.

03 Karsa Quantum OS · platform modules 01-06

The six control-plane modules, feature by feature

Module	Implemented features	Contract it speaks
Command Center	Tracked-task and queue counters, configured-backend count, module count. Core-coverage cards linking each control-plane function. Use-case accelerator cards. Canvas bar chart of platform activity. Live operational event feed. Connection pill showing Local simulation, Adapter online · simulator unreachable, or Live control plane · n/m systems.	Aggregates from local state or `/api/health`
Task Management	Create a canonical task: name, workload type (Quantum Chip Task, Cluster Simulation, Classical Benchmark, Session-Based Task), backend selector across all six backends, priority. Live table with per-row action. Automatic lifecycle progression. Session grouping (`SESS-nnnn`). Cancellation. Task event log. Job cap of 60 with FIFO trim.	`MsgTask` → `MsgTaskAck` → `MsgTaskResult`; status via the numeric `TaskStatus` enum
Resource Management	Health cards plus a 13-column inventory table: backend, system, qubits (available/total), Router and Pub port, max shots, native gate set, access mode, queue depth, utilisation, fidelity, latest calibration, scheduling state, action. Pause and resume scheduling. Manual M3 sampling utility. Optimal qubit block query. Resource log.	Mirrors `ChipConfig/chip_config_mapping.json`; maps to PilotOS §5.11–5.14
Status Monitoring	Per-backend health grid, refresh control, queue and throughput trend chart, alert and event feed with severity classes, monitoring log. Consumes the four Pub topics as event classes.	`task_status` · `probe` · `calibration_done` · `chip_protect`
API Console	Endpoint selector grouped by system and port, with pattern, endpoint and message type readout; request and response payload panes; per-endpoint explanatory note including known defects; send button that replays a recorded payload offline and dispatches a real ZMQ message when live. Task-creating operations are marked so read-only queries no longer fabricate tasks.	20 endpoints across Router 7000–7003, Pub 8000–8003, plus two error paths
Access & License	Provision a user or group with role and access profile; four seeded roles; remove an entry; licence verification returning the enabled feature set — Dashboard, Resource Management, Task Management, Queue Insight, API Management, Session Tasks. Governance log. Input validation with `aria-invalid` on empty submit.	Wraps the PilotOS console's user and licence model with an enterprise layer

03 Karsa Quantum OS · use-case modules

Four of the six security modules, feature by feature

07 · PQC Migration Optimizer

Inputs — programme budget (2–12), engineer capacity (2–12), deadline (2–12), optimisation mode
Modes — classical baseline · quantum-inspired · QAOA simulator via the control platform
Outputs — modelled risk reduction, selected programme cost, assets selected, solution-quality proxy
Views — objective chart, migration wave timeline, per-asset decision table with current crypto, risk, cost, engineers and decision
Asset set — 7 governance assets: Core Banking PKI, Treasury HSM Policy, Mobile Banking API, Data Lake Encryptor, Partner Gateway, HR Signature Workflow, IoT Telemetry Hub
Split — business scoring and QUBO formulation are Karsa; the control plane orchestrates the execution pattern

08 · PQC Benchmark Lab

Algorithms — ML-KEM-768, ML-DSA-65, SLH-DSA-128s
Target profiles — Server, Mobile, Edge / IoT
Controls — iteration count 100–100,000, submit with live progress bar and state readout
Metrics — key generation, operation A, operation B, normalised throughput, comparison chart
Stated boundary — PQC algorithms run on classical computers; the control plane contributes orchestration, allocation, lifecycle and monitoring, not the cryptographic primitive

09 · Quantum Exposure Simulator

Inputs — confidentiality lifetime 1–25 yr, migration lead time 1–10 yr, threat horizon 5–30 yr
Scenario — conservative (−3 yr), moderate (0), optimistic (+3) applied to the horizon
Output — signed exposure window with CRITICAL / HIGH / MEDIUM / LOW band, timeline markers for migration-ready and threat horizon, decay chart
Role — single-asset calculator; see module 10 for the portfolio version
Stated boundary — no cryptographic attack is performed; planning assumptions only

12 · Integration Architecture

Interactive map of 10 components, filterable by Native / Adapter / Custom, keyboard-operable with aria-pressed state
Components — PQC Migration Platform · Karsa Quantum Adapter · Quantum Control Plane · QPanda3 SDK · PQC Runtime Service · HNDL Batch & Vault Lab · QKD Security Lab · Optimization Service · Simulator or QPU · HSM / Key Vault / PKI
Ownership table — CBOM, PQC discovery, PQC runtime, key protection, HNDL/QKD engines, migration optimisation, control-plane connector, governance, each with owner and implementation approach
Design principle it encodes — enterprise cryptographic protection stays deliberately outside the quantum control layer

03 Karsa Quantum OS · use-case modules 10-11

The two newest modules, feature by feature

Both close gaps this brief identified in an earlier pass — a portfolio-scale HNDL engine and a working QKD protocol simulator — and both are live in the app today, not on the roadmap.

10 · HNDL Batch & Vault Lab

Inputs — migration lead time 1–10 yr, threat horizon 5–30 yr, scenario (same −3/0/+3 convention as module 09)
Scope — all 7 assets from the Migration Optimizer's inventory, scored in one pass with a shared threat horizon and each asset's own confidentiality lifetime
Outputs — assets scanned, count already CRITICAL/HIGH, per-asset exposure window and P0–P3 wave, sorted most urgent first, urgency bar chart
Synthetic vault — on demand, generates 10–14 weighted synthetic session records: session ID, asset, algorithm, capture date, classification, retention, projected decrypt-by year — plus captured-volume, sensitive-share and urgency-band summary metrics
Dispatch — queues the batch scenario as a control-plane job on CPU Pool A, visible in Task Management and the dashboard counters
Stated boundary — no real network traffic is captured or analysed; all records are generated in-browser

11 · QKD Security Lab

Protocols — BB84, decoy-state BB84, E91, B92 (B92's lower conclusive-detection rate is modelled explicitly — roughly half the sifted key of BB84 at equal pulse count)
Channel model — distance-based fibre loss (0.2 dB/km), detector efficiency, dark-count rate, a fixed intrinsic noise floor, all run through a real per-pulse loop with a seeded PRNG
Eve strategies — none, intercept–resend (variable probability), photon-number splitting, detector blinding — the latter two modelled as stealth attacks that do not raise QBER, only caught by a decoy-state check or an optical-power-monitor toggle
Outputs — sifted key length, measured QBER, a derived (not hardcoded) ~11% security threshold, an illustrative secure-key estimate via the asymptotic Shor–Preskill bound, ACCEPT/ABORT verdict, and a full run trace
Acceptance table — repeatability, noise calibration, Eve sensitivity and operational integration, scored live against the current run
Dispatch — queues the scenario as a control-plane job on PQPUMESH8, the estate's photonic backend

03 Karsa Quantum OS · backend estate and state model

Six backends, four modalities, one status enum

The inventory the platform serves, mirroring the bundled Python simulator's own chip configuration — qubit counts, shot ceilings and native gate sets are the values it actually returns.

Backend	System	Router / Pub	Qubits	Max shots	Native gates	Access mode	Scheduling
Origin Wukong 72Q	superconducting	7000 / 8000	60 / 72	20,000	RPhi, CZ	Exclusive window available	ACTIVE
Superconducting_72_2	superconducting	7000 / 8000	60 / 72	20,000	RPhi, CZ	Shared	ACTIVE
IonTrap	ion_trap	7001 / 8001	6 / 6	10,000	RPhi, MS	Token authenticated	ACTIVE
HanYuan_01	neutral_atom	7002 / 8002	225 / 225	20,000	RPhi, CZ	Maintenance window	PAUSED
PQPUMESH8	photonic	7003 / 8003	3 / 3	100,000	CZ, RPhi	Shared	ACTIVE
CPU Pool A	classical	—	—	—	N/A	Shared	ACTIVE

UI lifecycle mapped to the simulator's numeric enum

QUEUED → PENDING 1 RUNNING → RUNNING 2 COMPLETED → SUCCESSED 5 FAILED → FAILED 4 CANCELLED → CANCEL 11 also: NOTASK 3 · RETRY 6 · COMPILING 7 · COMPILED 8 · SUBMIT 9 · FINISH 10 · SUBMITFAIL 12 · RUNFAIL 13 · WAITING 14

Why PQPUMESH8 matters more than its three qubits suggest. It is the photonic entry in the estate, and photonic is the modality a future QKD backend would attach through. A three-qubit photonic simulator is useless for computation and exactly right for proving that the integration contract, the scheduling path and the telemetry conventions work before any optics are procured.

03 Karsa Quantum OS · API Console contract coverage

Twenty endpoints, recorded from a live simulator run

Payloads in the console are not hand-written examples. They were captured from an actual run and are replayed offline, or dispatched for real when the adapter is present.

Operation	System · port	Behaviour
MsgHeartbeat	superconducting · 7000	Liveness; returns backend, timestamp, topic
MsgTask	superconducting · 7000	Ack first, then `MsgTaskResult` with Key / ProbCount / NoteTime
TaskStatus	superconducting · 7000	Query state — see the known-defect note
GetChipConfig	superconducting · 7000	QubitCount, AvailableQubits, CLOPS, MaxShots, MaxClockCycle, BasicQGate, keyed by work area
GetUpdateTime	superconducting · 7000	Per-qubit calibration timestamps
GetRBData	superconducting · 7000	Single and double gate circuit depths and fidelities, per qubit and qubit pair
SetVip / ReleaseVip	superconducting · 7000	Reserve and release an exclusive window
MsgGetToken	ion trap · 7001	APPId / APIKey / APISecret → access and refresh tokens
MsgUpdateToken	ion trap · 7001	Refresh an access token
MsgTask (OPENQASM)	neutral atom · 7002	Header/Body form; HanYuan_01 at 225 qubits

Operation	System · port	Behaviour
MsgAtomConfig	neutral atom · 7002	Documented but absent from the dispatch table — silently dropped
MsgTask	photonic · 7003	PQPUMESH8, 3 qubits, 100,000 max shots
GetChipConfig	photonic · 7003	Photonic chip architecture
task_status	Pub · 8000–8003	Three-frame push: topic, operation, JSON. Observed PENDING → RUNNING → SUCCESSED
probe	Pub · 8000	Qubit usage and worker-thread status
calibration_done	Pub · 8000	Paired with calibration_start; drives the calibration feed
chip_protect	Pub · 8000	Maintenance start/end → PAUSED state in Resource Management
Malformed payload	error path	`UndefinedMsg`, ErrCode 3 (JSON_ERROR)
Unknown ChipID	error path	ErrCode 2 (TASK_PARAM_ERROR)

Error-path coverage is not decoration. An integration surface is defined as much by how it fails as by how it succeeds. An unknown MsgType produces no reply at all — which is a materially different client problem from an error response, and exactly the kind of thing a contract explorer should make visible before someone writes a client against it.

03 Karsa Quantum OS · the adapter

One bridge, and it degrades gracefully

The adapter terminates the simulator's ZeroMQ Router and Pub sockets and re-exposes the same contract over HTTP and Server-Sent Events. It also serves the web application, so there is one process and one origin — no CORS, no second server to operate.

Browser · Karsa Quantum OS

Ten static modules. Opens no socket, holds no credential, reaches no QPU.

HTTP + Server-Sent Events

Karsa Adapter

Terminates ZMQ · serves the app · one origin · compensates for wire-level defects so the browser sees a clean contract

ZMQ Router (REQ/REP) + Pub (SUB)

Python simulator, or Origin PilotOS backends

Four systems, Router 7000–7003, Pub 8000–8003

Adapter API surface

GET /api/health	Boot probe, 1.5 s timeout. Returns adapter state and per-system connectivity
GET /api/backends	Live chip inventory
POST /api/task	Canonical submission — system, chipId, shots
GET /api/task/{id}?system=	Task status by system
POST /api/message	Arbitrary typed message, with a collect count
POST /api/message (raw)	Raw string — used to exercise the malformed-payload path
POST /api/token	Ion-trap token brokerage
GET /api/topics	Pub buffer: per-topic counts and recent frames
GET /api/events	SSE stream: task_status, probe, chip_update, calibration_start, calibration_done, chip_protect

Three connection modes, never fatal

live — adapter answered and systems are connected; operational pages drive from real simulator data
degraded — adapter is up but no Router port answered, or the event stream closed; surfaced honestly in the UI
local — no adapter detected; the platform behaves exactly as it did before the adapter existed

Every call is optional and failure is never fatal. That is a deliberate design property: a demonstration must not depend on a backend being reachable.

Compatibility shims, and why they are temporary. The adapter sends both TaskId and task_id, and both ChipID and ChipId, so queries resolve against the real server despite documented casing defects. The correct fix is upstream; the shim exists so the browser sees a clean contract in the meantime and is scheduled for removal once the simulator is patched at source.

03 Karsa Quantum OS · verified by running it

Twenty-six checks passed. Seven defects found.

The simulator was validated against a live run, not against its README — reproducible with verify_simulator.py. Three of the defects would have blocked any real client. The source was deliberately left unmodified pending review.

26/ 26

Checks passing against a live run

Defects documented with exact line numbers

7/ 7

Task-lifecycle checks passing end to end

~100ms

Typical turnaround, submit to result

Severity	Defect	Consequence
Blocking	Client identity decoded as UTF-8	Drops every request from a standard ZMQ client — including the simulator's own bundled test client. Nothing that speaks the protocol correctly can connect.
High	TaskStatus reads the wrong field	The server reads snake_case `task_id`; the documented `TaskId` query never resolves — returning NOTASK even for a task that just succeeded.
High	Ion trap auth rejects its own credentials	The handler reads a lowercase `body` with APPId / APIKey / APISecret. The documented Body / AppId / ApiKey form returns ErrCode 5 with the exact credentials the server expects.
Lower	Four further defects	Chip-ID casing inconsistency, one documented-but-unimplemented message (`MsgAtomConfig`), and two silent failure paths where an unknown message type produces no reply at all.

Why this belongs in a security brief. Every one of these is an integration defect, not a cryptographic one — and integration defects are how security platforms actually fail. A silent drop, a query that never resolves, an authentication path that rejects valid credentials: each of these would produce a security tool that reports a clean result because it never got an answer at all. Verifying the contract by running it is the same discipline as the QryptOn scanner's insistence on negotiated rather than declared evidence.

Part 04 of 07

QryptOn

The layer that actually protects traffic: a readiness scanner, a browser toolkit, and the pure-Rust library underneath both.

04 QryptOn · the offer

Understand, check, act — two of the three are free

QryptOn is deliberately scoped to post-quantum cryptography rather than to security in general. It is the only layer in this brief that touches real cryptographic material.

01 · Understand

The threat model, without hype. What Shor and Grover actually do, harvest-now-decrypt-later with a working Mosca calculator, the three finalised standards side by side, and the regulatory picture — each claim sourced, or explicitly marked as needing a source.

02 · Check free

Local toolchain PQ scanner. A read-only POSIX shell script. Can the crypto libraries and CLI tools on this host negotiate post-quantum TLS and SSH today? Scored, capped, with confidence stated — and nothing leaves the machine by default.

03 · Act free

Browser PQC toolkit. Generate a hybrid identity, password-protect it, encrypt to someone's public key, sign and verify — all in WebAssembly on your own device, in the same file formats the qrypt CLI reads and writes.

Offline, deterministic, and there is no AI in it

Scanning and scoring are plain shell logic — version parsing, grep, and exit-code checks against openssl, curl, ssh, go, node and python3. No language model, no classifier, no remote decision service at any step. Same host, same tools, same result, every time. The whole script is wrapped in a function invoked on the last line, so a truncated download cannot run a partial check.

Why this matters next to a simulator. Karsa Quantum OS models exposure. QryptOn measures it, on a real host, with commands you can read before you run them. A risk model calibrated against nothing is a spreadsheet; the scanner is what gives the exposure engine ground truth.

04 QryptOn · scanner invariants and checks

Seven invariants, seventeen checks, nine that score

Invariants, stated in the source

Read-only — nothing written outside a scratch directory removed on exit
No root required — anything needing root reports "unknown", never guessed
No persistence — no dotfiles, cron, profile edits or systemd units
No network by default — --online allows exactly one TLS probe, revealing this host's IP and nothing else
Nothing transmitted without --share — affirmative consent, fails closed with no terminal
Bounded — 45 s total, 5 s per check, 256 KiB output cap, all enforced
Deterministic — no AI in scanning or scoring

Verify before you run. Download the script, check the published SHA-256, read it — plain POSIX sh, not obfuscated — and only then execute. Supported on dash 0.5+, bash 4+ in POSIX mode, and BusyBox ash.

Scoring model v2026.09 — 90 of 100 points on key exchange

Check	Category	Weight
kex.tls.openssl.groups	TLS	40
kex.ssh.client.mlkem	SSH	15
kex.tls.live.hybrid	TLS · negotiated	12
kex.ssh.client.effective	SSH	10
kex.tls.curl.pq	TLS · negotiated	8
kex.ssh.client.sntrup	SSH	5
runtime.go / node / python	Runtime	4 / 3 / 3
pki.signature.mldsa / slhdsa	Signatures	0 · reported
hygiene.os / tls13	Hygiene	0 · reported

Structural caps beat arithmetic. If the primary TLS stack was tested and has no ML-KEM, the score is capped at 40 and labelled "Blocked at TLS" — no combination of runtime passes talks over that. If TLS could not be tested at all, no verdict is issued: that is not established, not a score of zero. Below 75% confidence the band is withheld rather than guessed. --profile cnsa2 adds three unscored checks for ML-KEM-1024 and ML-DSA-87.

04 QryptOn · toolkit and library

Four tools, nine crates, zero uploads

The toolkit — Qryptonite compiled to WebAssembly

Tool	What it does
Generate identity	One identity bundles an encryption key (X25519 + ML-KEM-768) and a signing key (ML-DSA-65) — the same format `qrypt keygen --alg qrypton-identity` produces
Protect a key	Wrap a private bundle with a password using Argon2id + AEAD, with a live strength meter; unlocks protected keys too
Encrypt / decrypt	Hybrid X25519 + ML-KEM-768 seal to a public armor text; the recipient needs only their private key
Sign / verify	ML-DSA-65 detached signatures under FIPS 204, bound to a QryptOn identity

Component	Algorithm	Size
Encryption key	X25519 + ML-KEM-768	1184 B public
Signing key	ML-DSA-65	1952 B public
Signature	FIPS 204	3309 B
Password wrap	Argon2id + AEAD	—

Qryptonite — nine crates, one direction of dependency

qryptonite-wasm

Powers the browser toolkit

-cli · -ffi

The qrypt tool · C ABI binding

qryptonite-hl

Seal/open, sign/verify, keystore, identity, armor

qryptonite-hybrid

Hybrid KEM, composite signatures

-pqc · -classic

FIPS 203/204/205 · AEAD, X25519, Ed25519

qryptonite-core

Traits and types — zero algorithm dependencies

Why not liboqs. Most PQC libraries wrap the liboqs C library. Qryptonite deliberately does not: liboqs has no SLH-DSA support, and a C/CMake toolchain is hostile to the clean WebAssembly build the toolkit needs. Every algorithm is pure Rust from the RustCrypto ecosystem. Verified: ML-KEM, ML-DSA and SLH-DSA pass NIST ACVP known-answer vectors; two fuzz targets run without a discovered crash; cargo-deny clean; documentation coverage enforced at compile time. Dual-licensed Apache-2.0 OR MIT.

Stated plainly, on every relevant page: Qryptonite is not FIPS 140-3 validated, has not undergone an external security audit, and is pre-1.0.

04 QryptOn · standards

What is implemented, not just mentioned

NIST finalised three post-quantum standards in August 2024. This is what QryptOn actually implements — not every parameter set every standard defines.

Standard	Algorithm	In use	Public key	Signature / ciphertext	Status
FIPS 203	ML-KEM	ML-KEM-768 (cat. 3)	1184 B	1088 B ct	Live
FIPS 204	ML-DSA	ML-DSA-65 (cat. 3)	1952 B	3309 B sig	Live
FIPS 205	SLH-DSA	All 12 parameter sets	—	—	Library only
FIPS 206 (not yet drafted)	FN-DSA (Falcon)	—	—	—	Tracked
Round 4 selection	HQC	—	—	—	Tracked

Why hybrid, not pure PQC

Every encryption operation combines X25519 with ML-KEM-768. The shared secret is compromised only if both components are broken, so the deployment loses nothing if an unknown weakness later appears on either side.

Why SLH-DSA waits

All 12 parameter sets are implemented, but the pure-Rust backend is still a release candidate. It is deliberately excluded from the WebAssembly build to keep the download small and the stability risk contained.

A working vendor-credibility test

As of mid-2026 NIST has published no draft of FIPS 206 and has assigned no FIPS number to HQC. Anyone selling compliance with a standard that does not exist yet is telling you something useful about their other claims.

Part 05 of 07

Correlation

Attack by attack: which layer simulates it, which layer mitigates it, and which layer must not claim it.

05 Correlation · the master map

Eight attacks, three platforms, two verbs

Simulate and mitigate are different jobs and they land on different layers. Where a cell is empty that is a finding, not an omission.

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 across the asset inventory plus a synthetic harvest-snapshot generator, live in the app	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 resource 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 from RSA — cheaper attack, higher urgency	Mitigates. Hybrid X25519 + ML-KEM-768 seal	Asset scoring needs ECC weighting
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 backend integration exists; no QKD application in the control plane itself	Simulates. QKD Security Lab — a real per-pulse BB84/decoy-state/E91/B92 Monte Carlo with channel, detector, and four Eve strategies, live in the app	Supplies the authenticated classical channel a real QKD link requires	Prototype built — external validation pending
Downgrade / hybrid stripping	—	Should surface fallback posture as an inventory attribute	Detects. `--online` completes a real TLS 1.3 handshake offering only X25519MLKEM768 — negotiated, not declared	Covered by evidence classes
Trust anchor & code signing	—	Migration Optimizer already carries Core Banking PKI and HR Signature Workflow as assets	Reports ML-DSA and SLH-DSA availability; certificate-in-use analysis is on the roadmap	Partial — PKI depth still to come
Crypto-agility failure	—	Inventory, CBOM and approval workflow are Karsa-owned and named in the architecture map	`--fail-under N` exits non-zero for CI — the scan becomes a pipeline gate, not a report	Covered, if operationalised

05 Correlation · HNDL end to end

HNDL: a complete pipeline, and four of five stages already exist

Stage 01 · measure

Ground truth

QryptOn 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

→

Stage 02 · inventory

CBOM & classification

Karsa. Asset schema, crypto dependency per asset (RSA / ECDH / ECDSA), data classification, secrecy lifetime, retention value, business owner.

Seeded — 7 assets

→

Stage 03 · model

HNDL vault & exposure

Karsa. Per-asset exposure window across all seven inventory assets under one threat-horizon scenario; synthetic ciphertext + metadata vault, weighted toward the most urgent assets; which sessions stay sensitive if key establishment breaks later.

Built — HNDL Batch & Vault Lab

→

Stage 04 · execute

Batch orchestration

PilotOS. Thousands of parameter combinations submitted as managed workloads: queueing, priority, retry, monitoring, evidence capture. Session mechanism keeps one study together.

Native

→

Stage 05 · act

Migrate & verify

Karsa + QryptOn. 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 · loop to close

Why the control plane earns its place here. For a single asset this arithmetic runs in a spreadsheet. The case for orchestration 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 Z, under several scenarios, and keep the evidence. That is a batch job with a lifecycle, a queue and an audit trail, which is precisely what PilotOS is.

The synthetic-by-design rule. The harvest stage uses generated lab traffic, synthetic PCAPs or approved captures — never production interception. The vault stores ciphertext and 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.

05 Correlation · QKD Security Lab

The QKD lab: built as a domain service behind the same control plane

Reuse the queueing and telemetry conventions; expose QKD-specific parameters and results. QKD is not modelled as an ordinary chip-compute task — and as of this build, the engine on the left is live.

User / API

QKD scenario

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

→

Karsa service · built

QKD engine

Per-pulse state preparation, channel model, attack injection, basis sifting, QBER estimation, and the asymptotic privacy-amplification bound, live in the QKD Security Lab.

→

Control plane

Orchestration

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

→

Execution · built

CPU → photonic

Classical Monte Carlo, shipping today. Photonic simulator and real optics remain future stages, added only if the economics justify it.

Protocol profiles

BB84 — baseline educational and security model Live
Decoy-state BB84 — multi-photon risk and decoy statistics Live
E91 — entanglement-based research scenario Live
B92 — reduced-state protocol comparison Live
MDI-QKD — the countermeasure family for detector attacks Planned

Attack and disturbance profiles

Intercept–resend and basis guessing Live
Photon-number splitting against weak coherent pulses Live
Detector blinding and faked-state injection Live
Dark counts and channel loss Live
Time-shift, dead-time, and malicious-vs-loss discrimination Planned

Outputs and acceptance criteria

Repeatability	Seeded run reproduces sifted key and QBER exactly	PASS
Noise calibration	Baseline QBER follows the configured channel and detector model	PASS
Eve sensitivity	Intercept–resend raises QBER under controlled assumptions	PASS
Integration	Submit → queue → run → evidence through the adapter	PASS

Raw keySifted keyQBERSecret-key estimateAbort / accept

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.

05 Correlation · cryptanalysis

Use quantum compute for demonstration and estimation. Nothing else.

> Mode: Shor demonstration

> Target integer N = 15

> Quantum period finding → r = 4

> gcd steps → factors 3 × 5

> Backend: PQPUMESH8 · 3 qubits · 100,000 max shots

> Status: educational / research proof only

Circuit depthLogical qubits Physical-qubit estimateError-correction overhead Estimated runtimeConfidence interval on the estimate

Product rule. Label every output as "simulation", "demonstration" or "resource estimate". Never display RSA-2048 cracked unless an independently verified real experiment actually achieved it. This is a hard rule in the UI, not a guideline in a document.

What is realistic

Small Shor demonstrations — factoring toy integers is a genuine teaching and validation workload
Resource estimation for real key sizes — logical qubits, physical overhead, runtime, at current and projected error rates
Sensitivity analysis — how the estimate moves when the code, the error rate or the arithmetic changes. This is the honest way to track a moving threat horizon
Grover cost modelling for symmetric parameters — with the quadratic bound stated correctly

What is not

Any production-key break. The gap between 180 noisy qubits and <100,000 fault-tolerant qubits is three orders of magnitude and an unsolved engineering problem
Equating Grover with Shor. Symmetric cryptography has a different risk profile and a different remediation
Treating a resource estimate as a date. The estimate is a cost under stated assumptions; the calendar depends on hardware nobody has built

Where the honest value sits: a platform that can re-run its own resource estimates when a new paper lands is worth more than one that claims an attack. The estimate is the product.

05 Correlation · evidence-based capability assessment

Can this stack support each capability? Scored, with reasons.

HNDL risk & exposure modelling10 / 10

Built. HNDL Batch & Vault Lab sweeps all seven inventory assets against one threat-horizon scenario, live in the app — not just feasible on classical compute, shipping on it.

Synthetic HNDL attack-chain simulation10 / 10

Built. The vault generator produces weighted synthetic session records — asset, algorithm, capture date, projected decrypt-by year — with no live interception and no real decryption at any point.

PQC readiness measurement10 / 10

Already shipping. Deterministic, offline, bounded, with declared-versus-negotiated evidence classes and a CI exit code. This is the strongest capability in the stack.

PQC benchmark orchestration9 / 10

Classical workloads managed through the quantum job plane. Karsa supplies methodology and normalisation; the control plane supplies reproducibility across a shared environment.

QKD protocol & eavesdropper simulation9 / 10

Built. A real per-pulse BB84 / decoy-state / E91 / B92 Monte Carlo with channel, detector, and four Eve strategies — two of them stealth attacks that only a dedicated countermeasure catches. Entirely classical, seeded, reproducible.

Toy Shor / cryptanalysis demonstration8 / 10

Suitable for small factorisations and controlled research workflows on simulators or an optional QPU backend, with resource estimation as the real deliverable.

Native QKD capability in the control plane3 / 10

Unchanged, and correctly so. Photonic backends are documented, but PilotOS itself has no dedicated QKD application. The QKD Security Lab lives in Karsa's own app layer, not inside the control plane — exactly the separation this brief argues for.

Actual RSA-2048 / ECC break today1 / 10

Not realistic with present NISQ hardware, at any vendor. The platform should provide resource estimation, and must never claim real production-key compromise.

Assessment basis: Origin PilotOS 4.2 manual (v3.4, 29 Apr 2026), Origin Quantum public product and blog pages, the Karsa Quantum OS prototype source — now including the shipped HNDL Batch & Vault Lab and QKD Security Lab modules — the QryptOn scanner and Qryptonite documentation, and the NIST / NSA / CISA and Indonesian regulatory record — all reviewed 3 September 2026.

05 Correlation · 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 that is scoped honestly, because the overclaim invalidates everything next to it. These are the rules the product enforces.

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 — QBER against Eve, noise and channel
Orchestration, batching, telemetry and evidence capture through the control plane
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% QBER threshold for every implementation
That its exposure formula predicts Q-day
That any displayed primitive protects real traffic

QryptOn may claim

Deterministic, readable measurement of one host's TLS/SSH/runtime PQ capability
Hybrid X25519 + ML-KEM-768 encryption and ML-DSA-65 signing, in formats the CLI reads
NIST ACVP known-answer vector conformance for ML-KEM, ML-DSA and SLH-DSA

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 — a later-stolen private key opens past messages
Compliance with FIPS 206 or an HQC FIPS number that does not exist

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.

Part 06 of 07

Deployment architecture

Zones, processes, ports and data flows — and four topologies, from one laptop to a sovereign installation.

06 Deployment · the target picture

One control plane, three security engines, five planes

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.

Karsa security

QKD Security Lab

Protocol · channel · detector · Eve · QBER · key metrics · abort/accept

Karsa security

HNDL Simulator

Secrecy lifetime · harvest model · vault · threat horizon · exposure ranking

Karsa security

PQC Migration

Inventory · CBOM · ML-KEM / ML-DSA / SLH-DSA benchmark · roadmap · approvals

canonical jobs · policy · safety labels

Karsa Adapter & Policy Layer

Auth · token brokerage · canonical job contract · idempotency · state mapping · retry & fallback · evidence capture · ZMQ termination · SSE fan-out

submit · queue · monitor · results

Control plane — Origin PilotOS

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

execution targets

CPU pool · quantum simulator · photonic simulator · optional QPU

QPU is optional for the MVP. Real QKD additionally requires dedicated optical hardware and an authenticated classical channel

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.

06 Deployment · Karsa Quantum OS in detail

What actually runs, where, and on which port

Three network zones and five process groups. The browser tier holds no credential and opens no socket to anything but the adapter.

Zone A · client tier

Browser — Karsa Quantum OS · static HTML/CSS/JS, no framework, no CDN, no build step

State: localStorage under ksi_origin_*, shape-checked and reseeded on corruption

Egress: same-origin HTTP + SSE to the adapter only

Holds: no API key, no token, no private key, no ZMQ socket

Works fully offline in local mode

Zone B · application tier

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

HTTP · /api/health /api/backends /api/task /api/message /api/token /api/topics

SSE · /api/events — task_status, probe, chip_update, calibration_start, calibration_done, chip_protect

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

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

The only tier holding credentials

Zone C · execution tier

Python ZMQ simulator · Router 7000–7003, Pub 8000–8003, four modalities

Origin PilotOS · console 10020, HTTPS API surface, MySQL 8.0+, MongoDB 6.0+

Classical compute · CPU pool for PQC benchmarks and Monte Carlo

Optional QPU · Origin Wukong via PilotOS backend integration

External · HSM / key vault / PKI — reached by the security services, never by the browser

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 Pub topic or touch a database. Every capability the UI exposes is a capability the adapter chose to expose, under its own authorisation — which is what makes the adapter, not the console, the correct place to put policy.

06 Deployment · ports, protocols and flows

Every listener and every flow, in one table

Component	Port	Protocol	Direction	Carries · notes
Karsa Adapter	8080 (conv.)	HTTP	Browser → adapter	Static app, REST calls. Same origin as the app, so no CORS configuration is needed
Karsa Adapter	8080 `/api/events`	SSE	Adapter → browser	Six Pub topics fanned out as named events. Browser reconnects automatically; a closed stream surfaces as degraded
Simulator · superconducting	7000 / 8000	ZMQ Router / Pub	Adapter ↔ simulator	MsgTask, TaskStatus, GetChipConfig, GetUpdateTime, GetRBData, SetVip, ReleaseVip, MsgHeartbeat
Simulator · ion trap	7001 / 8001	ZMQ Router / Pub	Adapter ↔ simulator	MsgGetToken, MsgUpdateToken, MsgTask. Token-authenticated access mode
Simulator · neutral atom	7002 / 8002	ZMQ Router / Pub	Adapter ↔ simulator	OPENQASM MsgTask with Header/Body envelope. Status enum extends with SUBMIT 9, FINISH 10, CANCEL 11
Simulator · photonic	7003 / 8003	ZMQ Router / Pub	Adapter ↔ simulator	PQPUMESH8. The attachment point for a future QKD backend
Origin PilotOS console	10020	HTTP	Operator → PilotOS	Visual management console. Default `admin / admin123` — change on first boot
Origin PilotOS API	443	HTTPS	Adapter → PilotOS	QCloudServer gateway. Token obtained from `/management/pilotosmachinelogin` with an API key
MySQL	3306	TCP	PilotOS → DB	Structured metadata. Must bind to a routable address — never 127.0.0.1, because the PilotOS image is isolated. Expect 26 tables after initialisation
MongoDB	27017	TCP	PilotOS → DB	Circuits and raw measurement results. Requires `authorization: enabled` and `bindIp: 0.0.0.0`
SMTP	465	SMTPS	PilotOS → mail	Registration and chip event alerts. Required if multi-user registration is enabled
Licence verification	443	HTTPS	PilotOS → vendor	Outbound internet required. Expired licence suspends all functions — resolve before designing an isolated deployment
HSM / key vault	site-specific	PKCS#11 / REST	Security services → HSM	Private keys, trust anchors, machine identities. Never reachable from Zone A

06 Deployment · four topologies

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	Backends	Identity & secrets	Suitable for
T1 · Standalone	Browser only. `python3 -m http.server 8080`, or open the file directly	None — seeded local state	None	Demonstration, training, offline review. No network dependency at all
T2 · Single-host lab	Adapter + simulator on one machine, one origin, one process to start	Four simulated systems on 7000–8003	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; PilotOS on its own host with MySQL and MongoDB; CPU pool for PQC and Monte Carlo	PilotOS-managed simulators, optional QPU, classical cluster	Enterprise SSO at the proxy; API keys and tokens in a vault; HSM for any real key material	Production migration programmes: inventory, batch exposure modelling, benchmark campaigns, evidence retention
T4 · Sovereign / isolated	Full T3, plus mirrored package repositories and an internal CA	On-premises PilotOS and simulators; QPU only if physically delivered	National PKI, on-premises HSM, no third-party dependency in the data path	Government and critical infrastructure. Requires resolving PilotOS licence activation, which needs outbound internet

Sizing, from the PilotOS manual's own baseline. The control-plane host wants 4+ modern cores, ≥ 64 GB DDR5 at 5600 MHz or better, ≥ 1 TB reserved storage and a 10 Gbps NIC — the last because quantum state space grows exponentially and the network must not become the bottleneck. The adapter and the Karsa security workers are comparatively light; the PQC benchmark and Monte Carlo pool is where you buy cores, not qubits.

Start at T2, not T3. Every acceptance criterion for the QKD and HNDL engines — seeded repeatability, noise calibration, Eve sensitivity, submit-to-evidence integration — is testable on a single host. Moving to T3 before those criteria pass buys operational complexity without buying confidence.

06 Deployment · controls that must exist before T3

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, and multi-user session handling in the adapter. This is explicitly the top item on the "move beyond localhost" list.
Authorisation	Adapter	The four console roles — Tenant Admin, Operator, Developer, Auditor — 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	PilotOS API keys, ion-trap APPId/APIKey/APISecret and database credentials live in a vault and are injected at runtime. Never in `localStorage`, 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 — a rule the architecture map states explicitly and the deployment must enforce with network policy, not convention.
Workload isolation	Execution	PQC cryptographic 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: 23 (backend send failure) is retryable; 25 (topology cannot execute this circuit) never is. Conflating them produces an infinite loop against an impossible task.
Evidence & audit	Adapter · PilotOS	Every security-relevant job keeps inputs, seed, backend, timestamps and outputs. PilotOS already provides tiered persistence — MySQL for metadata, MongoDB for payloads — and QCloudServer's task record supports full-lifecycle tracking and recovery. Use it rather than rebuilding it.
Safety labelling	Adapter · UI	Outputs carry their class — simulation, demonstration or resource estimate — through the API and into the UI. A label applied only at render time is a label that will eventually be lost in an export.
Egress control	Network	Zone A reaches only the adapter. Zone B reaches PilotOS, the HSM and the mirrors it needs. Zone C accepts no inbound connection from Zone A. PilotOS licence verification is the one documented outbound exception and must be explicitly allowed.

Part 07 of 07

Roadmap, status and sources

What is built, what is next, and where every claim in this brief came from.

07 Roadmap · recommended build sequence

Seven steps, ordered by value per unit of effort

Fix the simulator at source, then retire the shims

Apply the seven documented patches directly. The adapter's wire-level compatibility workarounds — dual-casing TaskId/task_id and ChipID/ChipId — exist only because the defects do, and every shim left in place is a divergence between what the contract says and what the client sends.

HNDL risk engine — batch, not slider Built

Shipped as the HNDL Batch & Vault Lab: the Exposure module's single-asset slider extended to a full seven-asset sweep with scenario modelling and a synthetic harvest-snapshot generator. This is what makes the control plane necessary rather than decorative, and it is the module a moving threat horizon makes indispensable.

Wire the Optimizer and Benchmark Lab to real submission

Both remain local-only because the simulator has no equivalent operation. Where one exists, dispatch through the adapter so benchmark campaigns and optimisation runs inherit the queue, the retry semantics and the evidence trail.

Synthetic HNDL laboratory Built — MVP

The HNDL Batch & Vault Lab generates weighted synthetic session records — asset, algorithm, capture date, classification, retention, projected decrypt-by year — synthetic by design, metadata only. Full PCAP-level object scenarios remain a future enhancement; the production-key boundary is enforced in the product, not a disclaimer.

Authentication and multi-user sessions in the adapter

The prerequisite for any shared deployment, and the gate between T2 and T3. Roles must become enforced scopes; secrets must move to a vault.

QKD BB84 MVP Built — exceeds MVP scope

Shipped as the QKD Security Lab: seeded channel model, four protocols (BB84, decoy-state BB84, E91, B92), four Eve strategies, QBER, sifting, and the asymptotic secret-key estimate — reproduced against analytic BB84 expectations in testing. What remains: validation against an independent QKD library or published reference vectors, before any physical photonic device is attached.

Photonic and QPU integration

Only after the software models, validation vectors, identity and telemetry contracts are stable. Simulator-first stays the architecture; a real QPU backend can be added later without changing the contract, which is the whole point of having one.

07 Status · where everything stands today

Current status, stated plainly

Karsa Quantum OS

Web control plane · 12 modules

Twelve modules simulate the full quantum operations command centre end to end, now including the HNDL Batch & Vault Lab and QKD Security Lab. Runs standalone from local state; the adapter is optional and never required.

Stable

Python simulator

4 systems · pyzmq

Verified against a live run, 26/26 checks. Seven defects documented with exact line numbers and proposed fixes; source intentionally left unmodified pending review. Three would block any standard client.

Documented

Karsa adapter

HTTP + SSE bridge

Live for task submission, resource inventory and monitoring across all four systems. Three connection modes degrade gracefully. Authentication and multi-user sessions are not yet implemented — localhost only.

Partial

QryptOn scanner

v1.1.0 · POSIX sh

Shipping. Seventeen checks, nine scored, structural caps, evidence classes, CNSA 2.0 profile, JSON schema v2, bilingual output, consent-gated sharing, CI exit code. PowerShell parity for Windows is next.

Live

Qryptonite & toolkit

9 crates · WASM

ML-KEM-768 and ML-DSA-65 live in the toolkit and CLI; all 12 SLH-DSA parameter sets in the library, held out of the WASM build while the backend is a release candidate. ACVP vectors pass. Not FIPS 140-3 validated, not externally audited, pre-1.0.

Live · scoped

HNDL & QKD Security Labs

Security extensions

Both now live in the app. HNDL Batch & Vault Lab sweeps the full asset inventory and generates a synthetic harvest snapshot; QKD Security Lab runs a real per-pulse BB84-family Monte Carlo with four Eve strategies, verified against analytic expectations. Neither is independently audited or claimed as production security.

Prototype live

07 Evidence · every claim, traced

Sources reviewed 3 September 2026

Origin Quantum

Origin PilotOS 4.2 — User Manual and API Reference, v3.4

29 April 2026. Architecture, seven kernel modules, console, 15 APIs, message push, type and error dictionaries, deployment and troubleshooting.

Origin Quantum

Origin Pilot product pages and download guide

Six core capabilities, deployment scenarios, Community and Enterprise editions, Origin Sīnán naming.

qcloud.originqc.com.cn/en/programming/pilotos · originqc.com/blogs/origin-pilot-download

Origin Quantum

Origin Wukong 180 specifications and China's 2026 machines

180 data qubits, 251 couplers, T1 40 µs, T2-echo 20 µs, 99.9% / 99% / 99% fidelities. Jiuzhang 4.0 and Hanyuan-2 comparison.

originqc.com/quantum-machines/quantum-computer · originqc.com/blogs/china-quantum-computers

NIST

FIPS 203 / 204 / 205 and IR 8547

ML-KEM, ML-DSA and SLH-DSA finalised 13 Aug 2024. IR 8547 initial public draft: deprecation after 2030, disallowance after 2035. FIPS 206 not yet drafted; HQC selected Mar 2025.

csrc.nist.gov/pqc

CISA · NSA · NIST

Quantum-Readiness: Migration to Post-Quantum Cryptography

Joint fact sheet, August 2023. Explicitly warns that long-life data can be harvested now and decrypted later; recommends inventory, risk analysis and roadmap.

NSA

QKD and quantum cryptography guidance · CNSA 2.0

QKD is partial, hardware-dependent, requires source authentication and special-purpose equipment; real security is implementation-dependent. CNSA 2.0 mandates ML-KEM-1024 and ML-DSA-87.

Gidney (Google Quantum AI)

How to factor 2048-bit RSA integers with less than a million noisy qubits

arXiv 2505.15917, May 2025. Under 1 M noisy qubits, under one week — a 20× reduction from Gidney & Ekerå 2019.

arxiv.org/abs/2505.15917

Iceberg Quantum

The Pinnacle Architecture — RSA-2048 with 100,000 physical qubits using qLDPC codes

arXiv 2602.11457, February 2026. Simulation and resource estimates, not experimental demonstration.

arxiv.org/abs/2602.11457

Google Quantum AI et al.

ECDLP-256 resource estimate with zero-knowledge disclosure

March 2026, with Ethereum Foundation and Stanford co-authors. Under 500 k physical qubits, ~9 minutes after key exposure; circuits withheld, verified by SNARK.

QKD security literature

Side-channel and implementation attacks on deployed QKD

Photon-number splitting, Trojan horse, detector blinding and faked state, time-shift, dead-time, phase remapping, EM side channels — with decoy states, optical isolation, monitoring and MDI-QKD as countermeasures.

BSSN · Kemenko Polkam

National PQC Migration Roadmap Task Force

Kick-off 25 June 2026 at BSSN Bojongsari; draft Presidential Regulation on the PQC migration roadmap as an output. Framework: inventory, risk analysis, prioritisation, migration plan, execution, monitoring.

Karsa Sibernetik

Karsa Quantum OS prototype · QryptOn scanner and Qryptonite

Feature inventories in Parts 03 and 04 are read directly from the prototype source and the published scanner and library documentation, not from marketing material.

qrypton.karsa-siber.com

Questions & discussion

Model the threat honestly.
Measure the estate. Then migrate.

Karsa Quantum OS simulates. QryptOn measures and protects. Origin PilotOS executes. The value is in keeping those three verbs separate — and in never claiming one when you have only done another.

qrypton.karsa-siber.com IQCSF on LinkedIn Origin PilotOS

Indonesia Quantum Computing and Security Forum · 2026 · Prototype and simulation only — no production system, production key, or real QPU is involved in anything shown in this brief.

The Quantum Attack Surfaceand How We Simulate It

Seven parts, one argument

Three systems, three jobs, one seam

The attack surface

Every quantum-relevant attack, and what it actually needs

Shor breaks. Grover only weakens.

Why key size cannot save RSA

Why Grover is survivable

Harvest now, decrypt later: the anatomy

Two ways to write the same inequality

Mosca's inequality — the test

Karsa exposure window — the priority

HNDL urgency is set by the data, not the system

Forward secrecy does not save you

Where Indonesian institutions concentrate risk

The cost of breaking RSA-2048 keeps collapsing

What produced the 2025 drop

Why a planning deck must track this

Elliptic curve falls first, and falls faster

The blockchain corollary

QKD in theory: eavesdropping leaves a mark

Nobody attacks the mathematics. They attack the optics.

What QKD is for, and what it is not for

Defensible positions

Claims to refuse

What real QKD requires

Why it does not replace PQC

Why it still belongs in the lab

Four failures that need no quantum computer at all

Downgrade and hybrid stripping

Trust anchors and code signing

Crypto-agility failure

Inventory drift

The clock is no longer a risk argument. It is a date.

Origin PilotOS

Origin Quantum's machines, and China's 2026 landscape

Origin Pilot — 本源司南 — China's first quantum OS

Stated design goal

Intended audiences, per the manual

Six layers, from user code to cryostat

A task, end to end

Seven kernel modules, and what each one owns

Two ZeroMQ patterns, chosen for two different jobs

Router–Dealer · request / reply

Pub–Sub · publish / subscribe

The console, feature by feature

Fifteen documented APIs — the integration surface

Push topics, type enums and the error dictionary

Deploying it, and keeping it alive

Hardware baseline

Software prerequisites

Deployment sequence

Documented failure modes

Six core capabilities — and the four things it does not do

Karsa Quantum OS

Twelve modules, six control plane, six security

The six control-plane modules, feature by feature

Four of the six security modules, feature by feature

07 · PQC Migration Optimizer

08 · PQC Benchmark Lab

09 · Quantum Exposure Simulator

12 · Integration Architecture

The two newest modules, feature by feature

10 · HNDL Batch & Vault Lab

11 · QKD Security Lab

Six backends, four modalities, one status enum

Twenty endpoints, recorded from a live simulator run

One bridge, and it degrades gracefully

Three connection modes, never fatal

Twenty-six checks passed. Seven defects found.

QryptOn

Understand, check, act — two of the three are free

01 · Understand

02 · Check free

03 · Act free

Offline, deterministic, and there is no AI in it

Seven invariants, seventeen checks, nine that score

Four tools, nine crates, zero uploads

What is implemented, not just mentioned

Why hybrid, not pure PQC

The Quantum Attack Surface
and How We Simulate It

Model the threat honestly.
Measure the estate. Then migrate.