Karsa Quantum OS
Simulation Progress Report
Joining the web control-plane platform with the Python quantum-systems simulator — what was reviewed, what was verified by running it, and what is live today, and the assessed path to QKD/HNDL security simulation.
What we'll cover
Five parts: where the project stands, what changed on the platform, what was verified on the simulator, what joining them made possible, and why it matters for security.
Karsa Quantum OSTwo systems, one platform
Karsa Quantum OS is a control-plane prototype. The Python simulator is an independent quantum-systems service. Each works standalone; this update is about the bridge between them.
Karsa Quantum OS
Ten operational modules simulating a quantum control plane: task lifecycle, resource orchestration, protocol-level testing, and PQC governance workflows — running standalone from local state.
the adapter
Python ZMQ Simulator
Four simulated quantum systems — superconducting, ion trap, neutral atom, photonic — implementing the published Router-Dealer and Pub-Sub measurement-and-control protocol, each with its own chip inventory.
Karsa Quantum OSSimulation
How the control-plane prototype models quantum operations, end to end.
Ten modules, one simulation surface
Each module reproduces a real operational surface of a quantum control plane — without needing a live QPU connection to demonstrate it.
| Task lifecycle | Submit → queue → run → complete |
| Backend visibility | 6 simulated backends, live inventory |
| Protocol testing | Full Router + Pub message set |
| Governance modeling | PQC risk, migration, benchmark |
Karsa Quantum OSSimulator
Four quantum systems, verified by running them — not by reading the README.
Four systems, one message contract
Python and pyzmq. Every system answers the same two patterns: a Router for requests, a Pub socket for status push.
7000 · Pub 80007001 · Pub 80017002 · Pub 80027003 · Pub 8003MsgTask, TaskStatus, GetChipConfig, MsgGetToken, and more — one reply per request.
Three-frame messages — topic, operation, payload — pushing task_status, calibration_done, chip_protect.
Karsa Quantum OSThe chip inventory behind each system
Read directly from the simulator's own configuration — qubit counts, shot ceilings, and native gate sets are the values it actually serves.
| Backend | System | Qubits | Max shots | Native gates |
|---|---|---|---|---|
| Origin Wukong 72Q | superconducting | 60 / 72 | 20,000 | RPhi, CZ |
| Superconducting_72_2 | superconducting | 60 / 72 | 20,000 | RPhi, CZ |
| IonTrap | ion_trap | 6 / 6 | 10,000 | RPhi, MS |
| HanYuan_01 | neutral_atom | 225 / 225 | 20,000 | RPhi, CZ |
| PQPUMESH8 | photonic | 3 / 3 | 100,000 | CZ, RPhi |
Karsa Quantum OSA task, from submission to result
Every value below is quoted from the published protocol specification — a real submit-and-measure cycle on the 72-qubit chip, and a live resource probe captured during multi-threaded execution.
Field names, task-ID format, and timing values are quoted directly from OriginQ's Superconducting and chip-resource protocol documents — not invented for this deck.
Karsa Quantum OSVerified by running it, not by reading it
verify_simulator.pySeven defects surfaced this way. Three would have blocked any real client. All are documented with exact line numbers; the simulator's source was left unmodified.
Karsa Quantum OSIntegration
The adapter that joins the platform to the simulator — and what runs live today.
One bridge, three hops
Browsers cannot open ZMQ sockets. The adapter is the boundary: it speaks ZMQ to the simulator and re-exposes the same contract as HTTP and a live event stream.
It also serves the web app directly — one process, one origin, no separate server to run.
It compensates for the wire-facing defects automatically, so the browser sees a clean contract — the simulator's source stays untouched.
Karsa Quantum OSWhat's live today
Karsa Quantum OSSecurity
Why this matters — the quantum threat to today's cryptography, and how the platform responds.
Harvest today, decrypt tomorrow
An adversary doesn't need a quantum computer today to threaten today's traffic — only the patience to store it. These are the Quantum Exposure Simulator's own default values, not an invented example.
Mobile Banking API — ECDH / ECDSA, risk score 90 in the PQC Migration Optimizer's own asset list. Traffic captured today must stay confidential for 10 years. If a cryptographically-relevant quantum computer arrives on the assumed 12-year horizon, and migration takes 4 years to complete once started, the exposure window has already closed before migration even begins.
Karsa Quantum OSFrom quantum threat to quantum-safe
Three stages — two of them already running in this platform.
Migration data is read from the live Benchmark Lab. The QKD stage is a roadmap concept, not a native control-plane function; a protocol/channel simulator must be developed separately.
Karsa Quantum OSDetecting an eavesdropper, by physics
An illustrative BB84 walkthrough — not simulator output. The current four systems are quantum-computing backends; a QKD channel is a different kind of system entirely. Concept
In idealized BB84, measurement in the wrong basis introduces detectable disturbance. The ~11% figure is an illustrative asymptotic threshold under specific assumptions; practical QKD security depends on finite-key analysis, hardware behavior, authentication, and implementation quality.
Karsa Quantum OSCan Origin Pilot support QKD & HNDL simulation?
Yes — as an orchestration and backend-management layer. The security logic itself must be added as dedicated Karsa services. Public Origin Pilot documentation reviewed on 2 Sep 2026 does not expose a ready-made BB84/QKD simulator or an HNDL attack module.
QKD is buildable — but it is not native
Origin Pilot already provides the control-plane ingredients: multi-modality access including photonic systems, job lifecycle, queues, monitoring, and hybrid orchestration. Karsa must supply the QKD security semantics.
Orchestrate & observe
Multi-backend access, task queueing, scheduling, status push, photonic backend integration, hybrid quantum-classical workflows, monitoring and alerting.
QKD protocol engine
BB84/E91/B92/decoy-state logic, basis selection, sifting, parameter estimation, error correction model, privacy amplification, abort/accept decisions and evidence output.
Physical QKD stack
Photon source, detector, dedicated fiber/free-space channel, timing, optical calibration, trusted-node design and authenticated classical channel.
Recommended QKD Security Lab
Treat QKD as a domain service behind the same operational control plane — reuse queueing and telemetry conventions, but expose QKD-specific parameters and results.
- BB84 — baseline educational and security model
- Decoy-state BB84 — model multi-photon risk and decoy statistics
- E91 — entanglement-based research scenario
- B92 — reduced-state protocol comparison
- Intercept–resend and basis guessing
- Channel loss vs malicious disturbance
- Detector inefficiency and dark-count noise
- Photon-number-related scenario modeling and denial/degradation
What the QKD simulator may claim — and what it may not
- Demonstrate protocol behavior under defined assumptions.
- Show how QBER and secret-key estimates change as Eve/noise/channel parameters change.
- Compare protocols, finite-key assumptions, losses and detector profiles.
- Exercise scheduling, batching, telemetry and evidence capture through the control plane.
- Prepare integration contracts for a future photonic/QKD backend.
- “Unconditionally secure” without qualifying the implementation and proof assumptions.
- “QKD implemented in software” as a production security control.
- Universal ~11% QBER threshold for every implementation and protocol.
- Authentication solved by QKD alone — the classical channel still requires authentication.
- Photonic-compute compatibility automatically equals QKD hardware compatibility.
| Acceptance criterion | Minimum evidence | Status |
|---|---|---|
| Repeatability | Seeded run produces the same sifted-key/QBER result | To build |
| Noise calibration | Baseline QBER follows configured channel + detector model | To build |
| Eve sensitivity | Intercept–resend increases QBER under controlled assumptions | To build |
| Operational integration | Submit → queue → run → evidence/result through adapter | Architecture ready |
HNDL is primarily a risk & timing problem
Harvest-now-decrypt-later does not require a quantum computer at the harvesting stage. The adversary stores encrypted information now and waits for a future cryptanalytically relevant quantum computer. CISA/NSA/NIST explicitly use this scenario to justify early quantum-readiness planning.
A safe HNDL “attack” simulator is synthetic by design
The objective is to demonstrate exposure, not to intercept production traffic. Use synthetic PCAPs, generated encrypted objects, or approved lab captures, then model which sessions remain sensitive when a future public-key break is assumed.
- Generate representative TLS/VPN/API traffic in a lab.
- Tag public-key dependency: RSA, ECDH/ECDSA, certificates, VPN handshakes.
- Attach data classification, secrecy lifetime and retention value.
- Store ciphertext + metadata only in the simulated “HNDL vault”.
- Do not claim RSA-2048 decryption on present hardware.
- Demonstrate Shor on toy integers / educational key sizes.
- Run logical/physical-qubit and runtime resource estimation for real key sizes.
- Translate exposure into migration priority and compensating actions.
Use quantum compute for demonstration & estimation
NIST states that sufficiently large quantum computers would threaten current public-key cryptography. That does not mean today's NISQ hardware can factor RSA-2048 or solve production ECC keys.
- Small Shor demonstrations: realistic.
- Resource estimation for RSA/ECC: useful.
- Actual production-key break today: not a credible platform capability.
- Symmetric cryptography has a different quantum risk profile; do not equate Grover with Shor.
One control plane, three security engines
The strongest architecture keeps the control plane generic and makes QKD, HNDL and PQC explicit domain services. This preserves backend portability and prevents quantum-compute semantics from being confused with cryptographic-protection semantics.
Build sequence & evidence base
Every asset the system tracks
What Karsa Quantum OS records, and what the simulator is built from — the full inventory behind this demo.
Karsa Quantum OSCurrent status
Karsa Quantum OSWhat's next
Karsa Quantum OSThank you
Karsa Quantum OS — Simulation Progress Report. Questions and discussion welcome.