NARAD-QC : Network Architecture for Routing, Authentication and Delivery in Quantum Communications
Role: Lead Researcher & Solo Developer : simulation engine, routing-policy calibration, authentication and key-distillation pipeline, parallel execution, API bridge, React console
Overview
In a quantum network, the shortest path isn't the best path. A short route can still fail because one fibre doesn't generate quality entanglement, a repeater has no free memory, or stored pairs decay before their neighbours arrive. NARAD-QC is a resource-aware quantum network simulator with a post-quantum-authenticated control plane. You draw a network of users, fibres and repeaters, and it ranks the feasible routes with an empirically calibrated service model, authenticates the chosen nodes with ML-DSA, delivers entanglement across the route, distils a BBM92 key and opens a live two-way AES-GCM session. Built on a discrete-event simulation kernel and a parallel trajectory engine, calibrated on 640 routed trajectories, and exposed through a hardened FastAPI bridge and an interactive React console.
The Problem
Quantum key distribution works beautifully between two points, and then distance kills it. Photon loss grows exponentially with fibre length, so real deployments need chains of quantum repeaters. The moment a network has more than one possible route, a new problem appears. Which one do you pick? Shortest distance ignores memory limits, swapping failures and decay, and hand-tuned weights don't generalise. A route that looks good on paper still has to be authenticated and actually deliver enough entanglement to distil a key. NARAD-QC was built to answer one question end to end. How can a quantum network dynamically select a reliable, authenticated, low-error path, and then prove it by establishing a key?
How It Was Built
Most quantum-network simulators stop at the physics. A repeater chain, a fidelity number, a plot. NARAD-QC is built the other way round. It starts from what an operator would actually do (draw a network, pick two users, ask for a key) and implements everything in between: route discovery, ranking, authentication, entanglement delivery, key distillation and an encrypted session.
The Pipeline
Every run follows the same nine-step flow, and a route only counts as a success when a key actually comes out the other end.
| Step | Stage | What Happens |
|---|---|---|
| 1 | Describe | The operator defines users, repeaters, fibres, memory slots, Bell-state-measurement capacity and multiplexing modes. |
| 2 | Discover | Candidate paths are enumerated through repeaters. Users can be endpoints but never transit nodes. |
| 3 | Filter | Paths that fail hardware limits or fresh-pair QKD quality constraints are rejected outright. |
| 4 | Rank | Calibrated models predict reliability, delivery latency and delivered quality. Survivors are ranked by the Routing Policy. |
| 5 | Authenticate | Selected nodes mutually authenticate with fresh ML-DSA signatures before any quantum resource is spent. |
| 6 | Deliver | A discrete-event simulation generates elementary pairs, allocates memory, executes swaps and handles failure and expiry. |
| 7 | Collect | BBM92 measurements with a biased-basis policy, then sifting and error estimation. |
| 8 | Distil | Cascade-style reconciliation, leakage accounting, Toeplitz privacy amplification and an endpoint key check. |
| 9 | Communicate | A two-way AES-GCM session opens on the distilled key. |
A ranking is only a prediction. If the top route fails during real execution, the orchestrator falls back to the next ranked candidate.
A Routing Policy That Is Fitted, Not Hand-Tuned
Ranking uses three bottleneck features of a heterogeneous path: its longest elementary span, its repeater count and its weakest multiplexed link. Three fitted models turn those into a predicted service reliability, a conditional delivery latency and a delivered quality, and the policy combines them into one score.
S = p(service) / T(pair | success) × U(quality)
Hardware feasibility and QKD quality stay hard gates. Reliability stays a continuous term. A hard admission threshold was tested and dropped because it wasn't stable. No routing weight is hand-picked.
Calibrated on 640 Trajectories
The models were fitted to routed trajectories produced by the simulator itself. 5 total distances (200–600 km) × 4 repeater counts × 4 multiplexing settings, 8 trajectories each, run across a parallel worker farm for about 3.8 hours of cumulative worker time. 617 of the 640 delivered a QKD-ready pair inside the slot budget, and the rest are recorded as failures rather than dropped. Modelled delivery times have a heavy tail (median 0.07 s, mean 0.64 s, worst case 17.5 s), which is why latency enters the score conditional on success.
What the Engine Showed
Two Monte Carlo studies characterise the physics layer before any routing sits on top of it. Every trial uses the same physical seed across the three swap-scheduling policies, so they face identical randomness.
Swap-scheduling policies, 2,400 trials (8 distances × 3 policies × 100 trials), success rate
| Total Distance | Max-Parallel | Sequential | Static Tree |
|---|---|---|---|
| 500 km | 100% | 100% | 100% |
| 700 km | 54% | 56% | 26% |
| 750 km | 23% | 29% | 17% |
| 1,000 km | 0% | 0% | 0% |
No policy wins everywhere. At 100 km the static balanced tree is fastest (8.5 s against 22 s and 48 s) but delivers the worst pairs (fidelity 0.71 against 0.88 for max-parallel), and by 700 km it loses about 300 stored resources per trial to memory expiry. 1,000 km defeated every policy.
Repeater density at 600 km, 2,100 trials (7 repeater counts × 3 policies × 100 trials), success rate
| Repeaters | Max-Parallel | Sequential | Static Tree |
|---|---|---|---|
| 3 | 1% | 1% | 1% |
| 4 | 5% | 3% | 0% |
| 5 | 34% | 31% | 24% |
| 6 | 80% | 57% | 55% |
| 7 | 90% | 94% | 82% |
| 8 | 94% | 96% | 95% |
| 9 | 93% | 98% | 92% |
Density has a knee: success jumps from 5% to 80% between four and six repeaters, then flattens. The best policy flips with density too. Max-parallel leads by 23 points at six repeaters, and sequential leads at nine.
A scheduling rule that wins at one distance or density loses at another. That is the case for modelling each path, not trusting a rule of thumb.
Engineering Decisions That Mattered
Parallelism That Doesn't Lie
CPU workers, quantum lanes and optical modes are three separate controls. More workers speed up computation. More lanes change the modelled physical provision. A one-time benchmark confirms the parallel engine is physics-equivalent to the reference before a hard worker cap is written to configuration. If the process farm falls back to direct execution, the console reports the applied worker count, not the requested one.
From Notebook to Service
The engine was born in a Colab notebook and converted into a standalone FastAPI service with a Docker Compose setup. Calibration artifacts are version-checked, so a mismatched model refuses to load.
An API That Assumes Bad Input
Every operational route requires an API key. Job submission is idempotent: retrying a request ID reuses the job, and changing the payload under the same ID returns a conflict. Job and event payloads never carry raw key material or QKD bits. Sessions expire and can be destroyed on demand.
Messaging Without Nonce Reuse
Both directions share one key, so nonce discipline matters. Each 96-bit nonce is a random four-byte session prefix plus a 64-bit counter, allocated under a session lock across both directions, so concurrent sends from Alice and Bob never collide. Tampered ciphertext fails AES-GCM authentication.
Honest Telemetry
A key-yield forecast reading 100% is not a completed session. Messaging unlocks only after reconciliation and privacy amplification actually succeed. Demo mode is clearly labelled, and its animations and keys are never presented as backend results.
The Console
A React 19 + Vite interface with an SVG topology canvas. Users and repeaters are draggable, memory, BSM and fibre properties are editable, and graphs import and export as JSON. Coloured directional arrows follow the protocol stage: blue for routing, purple for authentication, amber for generation and swapping, teal for distillation, green for an established session and red for failure. Live telemetry shows pair budget, QBER and key-yield forecast, with separate composers and inboxes for Alice and Bob and downloadable logs. High-frequency physical events are sampled for display, so the interface stays usable rather than tracing every optical attempt.
Verification
15 backend integration tests, 9 frontend tests, a production build and browser checks of live telemetry and two-way messaging, recorded in October 2026. They cover graph constraints, authentication boundaries, idempotency, AES tamper detection, session expiry and concurrent nonce uniqueness. The backend and browser transport checks run on fixture trajectories with real AES-GCM. They do not replace a full physical run.
What It Doesn't Claim
| Limit | What It Means |
|---|---|
| Not hardware | NARAD-QC is a software simulation with no optical link and no device validation. The authentication and AES steps run real cryptography. The quantum layer is modelled. |
| Simplified physics | Pair quality uses a Werner-state abstraction with probabilistic generation, not a full state-vector or density-matrix simulation of the network. |
| Assumed parameters | Elementary fidelity, swap success, fibre attenuation and memory decay are assumed values. The decay rate is anchored to an assumed benchmark, not measured memory hardware. |
| Not a security proof | Key distillation is not a composable finite-key security proof. |
| Routing not yet benchmarked | The Routing Policy is fitted with cross-validation, but it has not yet been benchmarked head-to-head against shortest-path or equal-weight routers. |
| Bounded calibration | Models were fitted on 200–600 km, 2–8 repeaters and 1–16 multiplexing modes. Outside that range, predictions are extrapolation. |
| Trusted controller | ML-DSA authenticates node identities, but the controller remains a single point of trust. The console shows both peers to one operator, so it is not a production messaging service. |
| Local by design | There is no public server, because the engine is compute-heavy. The demo video shows a live run, and the repository runs locally or in Docker. |
Where It Sits
NARAD-QC is the third step in a line of work. CrypTon proved point-to-point quantum key distribution with AES. QBioAuth introduced a detailed post processing system, distance affected QKD and biometric authentication on top of the basic point-to-point QKD. NARAD-QC asks what happens when the point-to-point link becomes a network.
Results & Impact
Calibrated a routing policy on 640 routed quantum-network trajectories and characterised the engine across 4,500 Monte Carlo trials (a 2,400-trial swap-scheduling study and a 2,100-trial repeater-density sweep). Delivers a complete route-to-key pipeline, from path ranking and ML-DSA authentication to a two-way AES-GCM session, behind an authenticated, idempotent API and a React console with live telemetry. Backed by 15 backend integration tests and 9 frontend tests.