Quditto: Emulating and Orchestrating Distributed QKD Network Deployments

arXiv:2512.15408 · quant-ph · Submitted 2025-12-17 · Read on arXiv

Listen

Radio episode about this paper

Transcript

Introduction to the show: ident: Quantum Radio. Generated commentary on the latest quantum physics and condensed matter papers.

Kai: Today's paper: "Quditto: Emulating and Orchestrating Distributed QKD Network Deployments".

Mira: The gist: Quditto is an automated open-access emulation platform that combines high-fidelity quantum-channel modeling with a standardized key-delivery API,

Kai: First, who's behind it and why it matters.

Paper summary: Kai: So we’re looking at this paper titled "Quditto: Emulating and Orchestrating Distributed QKD Network Deployments". What's the main idea here, Mira?

Mira: Basically, they've built a platform that lets you simulate a whole distributed Quantum Key Distribution Network. The authors are claiming it bridges the gap between detailed quantum modeling and actually testing how these networks work in practice, like with real hardware.

Kai: Right, so it’s not just some abstract math thing; they’re making something you can interact with as if you had actual QKD gear connected to your computer. They call it Quditto because it coordinates the deployment of these networks automatically across different equipment.

Mira: Exactly. The core claim is that existing tools either model the physics really well or they simplify things too much for network studies, and this platform combines both high-fidelity modeling with a standardized key-delivery API, which is what makes it relevant for real hardware interaction.

Lev: From a hardware perspective, I’m interested in how modular this thing is. If you're trying to run error correction protocols on actual noisy equipment, you need something that handles the link level serialization correctly so the simulation doesn't just give you a perfect result that doesn't match reality.

Kai: Right, Lev brings up the real test. The paper describes Quditto as having three main parts: the orchestrator, the modeling engine, and then all those nodes that handle requests via a standard API. It sounds like it’s designed to be fully distributed across whatever classical infrastructure you have available.

Mira: That's what they claim. The orchestrator handles the setup—it installs the right software on your target devices and gets everything running as one coherent network, which is pretty neat because setting up complex lab environments is always a headache.

Lev: I wonder how robust that deployment mechanism really is when you move from a test bench to something more complex, like a multi-device topology. Does it handle the routing key exchanges in that setup smoothly?

Kai: The paper shows they handle those requests by having nodes publish "modeling request" messages specifying their neighbor and how much material they need, and then the modeling engine executes the protocol based on that. It’s an event-driven system, which means tasks run in parallel but things are still serialized at the link level.

Mira: That parallelism with serialization is key for keeping the quantum physics accurate while managing a large network structure. They also mention they built in support for different QKD protocols and variable attenuation and decoherence within the modeling engine itself.

Paper summary: Lev: So if you were trying to run a specific error correction code, you’d be looking at how accurately that protocol is implemented within that modeling core when things get messy on the link. That’s where I'd start digging for limitations.

Kai: They show validation results too, which is important. They mention deploying networks of various sizes and demonstrating flexibility through two proof-of-concept scenarios, which gives you a sense of how scalable it can actually be in practice.

Mira: And they specifically point out that in a partially adversarial environment, when an eavesdropper intercepts thirty percent of the qubits on the Quijote–Aquiles link, the exchange yields a Quantum Bit Error Rate of zero point one four eight four, which is above the secure threshold of zero point one one for BB84 protocol.

Lev: A QBER over that threshold means you’re in trouble for that specific protocol; it shows how quickly security breaks down when you introduce significant loss or interference on a link. That's a concrete number to work with, even if it’s just a simulation result.

Kai: And they also show how the platform supports complex key management schemes by allowing a Key Management Entity to orchestrate relaying through a trusted node, letting external components interact directly with those emulated nodes. That opens up possibilities for building more advanced systems on top of the network structure.

Mira: That ability to orchestrate key relaying is what makes this platform useful beyond just simulating simple point-to-point links; it lets you model the actual management layer of a larger network, which is where a lot of complexity lies.

Lev: So if we're talking about running this on real hardware, the question becomes how well their modeling engine translates those high-level protocol definitions into the actual physical constraints of the hardware they’re emulating. That translation fidelity is always a challenge in these setups.

Kai: Exactly, Lev. And looking at the overall design, it’s Python-based with Ansible for configuration, which suggests it's built to be deployed across existing classical equipment rather than being a standalone piece of software that requires you to rebuild everything from scratch.

Mira: That modular design is what I think matters most—it allows you to plug in different protocol implementations or even different quantum device models later on without rewriting the core orchestration logic. It’s built for extensibility.

Paper summary: Lev: Extensibility is good, but what about the computational overhead? Running high-fidelity quantum channel modeling and a message broker handler all at once across many nodes sounds like it could be demanding for resources if you're trying to scale up really big.

Kai: They show they deploy faster than even a two-node network in their previous service, which suggests efficiency is being prioritized in the deployment phase itself. But the modeling core does run parallel tasks for different links.

Mira: The paper does flag that they are using NetSquid as their simulator base, and while it’s powerful, you still have to contend with the assumptions inherent in that specific quantum simulator when mapping it to real hardware behaviors.

Lev: I agree. And what about the limitations? They don't detail every edge case, but the fact they are focusing on BB84 with Eve and Extended BB84 with user-configurable parameters tells us where their current focus is placed in terms of modeling imperfection versus full noise characterization.

Kai: So to wrap up this section, Quditto presents itself as a complete emulation platform that marries detailed quantum channel modeling with the ability to orchestrate distributed networks using a standardized API. It’s built for testing complex network behaviors across different scales and security scenarios.

Mira: And the implications are that researchers and engineers can test protocol robustness and key management schemes in this controlled environment before committing to expensive, physical QKD hardware deployments or waiting for real-world experimental setups to stabilize.

Lev: For someone running actual quantum error correction software, this means you get a reliable sandbox where you can test how your error correction routines perform when interacting with the expected noise profiles derived from the modeling engine.

Kai: So we’ve looked at what Quditto is and what it claims to do in this paper on "Quditto: Emulating and Orchestrating Distributed QKD Network Deployments". What does that mean for us moving forward?

Mira: It means the next step is looking at how they plan to incorporate more protocols, like those with reconciliation or privacy amplification modules, to expand the range of security experiments they can run. That’s where the real expansion happens.

Lev: And for hardware-in-the-loop testing, that’s another direction mentioned; interfacing this platform directly with actual quantum hardware would be a huge validation step for their entire system.

Kai: So we've covered the summary, the conclusion, and what these authors are suggesting next for Quditto. That’s all we have time for today on this paper.

Conclusion: Kai: So, Quditto is basically this automated platform that lets you test huge quantum networks exactly like they would run in reality.

Mira: Yeah, the authors are showing how they combine very detailed quantum physics modeling with a standardized way to talk to actual network hardware APIs.

Lev: It sounds like they’ve put together a system for deploying and testing complex QKD setups without needing every single piece of equipment sitting on your desk.

Kai: Right, it’s about taking those distributed network descriptions and automatically setting up all the software across different classical devices and clouds to make them work.

Mira: What's interesting is they aren't just simulating a link; they’re orchestrating the entire deployment process, which means managing all those connections in a standardized way.

Lev: From my side, I’m thinking about how realistic that deployment is when you try to run actual error correction codes on it; you need to know if the simulation matches what real hardware would actually throw at you.

Kai: Well, they show some validation results where they deploy these networks and test things like a thirty percent eavesdropper attack, and the results give them concrete numbers about how much error the system produces.

Mira: That QBER of zero point one four eight four against a security threshold of zero point one one is a pretty solid data point showing that their model is capturing some real physics effects under stress.

Lev: But what they don't detail, and this is important for me, is how well this platform handles the kind of continuous, high-speed data flow you’d see in a truly massive network deployment.

Kai: So the authors are pointing toward two next steps: first, adding more complex QKD protocols with their reconciliation modules to test other security scenarios.

Mira: And second, they want to get this platform talking directly to actual quantum hardware for hardware-in-the-loop testing so they can see how it performs when interfaced with real devices.

Lev: That would be a big validation step; seeing if the software’s assumptions hold up when you’re feeding it real physical noise and imperfections from the equipment itself.

IMDEA Networks Institute · Telematic Engineering Department, Universidad Carlos III de Madrid

quant-ph

Submitted: 2025-12-17

Updated: 2026-10-08

Comments: \c{opyright} 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works

Journal ref: B. Lopez, A. Diaz-Bricio, J. Perez, I. Vidal and F. Valera, "Quditto: Emulating and Orchestrating Distributed QKD Network Deployments," in IEEE Network 2026

DOI: 10.1109/MNET.2026.3736912

Code: https://github.com/amartin-m/Non-ideal-QKDNs

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 82/100

The gist: The gist: Quditto is an automated open-access emulation platform that combines high-fidelity quantum-channel modeling with a standardized key-delivery API, enabling users to interact with an emulated

Key concepts

Quditto Orchestrator
This component automatically handles the entire deployment process of a distributed QKDN. It provisions target devices, installs necessary software stacks, sets up the message broker, and launches all required processes to create a fully operational network based on a user's description.
Quditto Modeling Engine
This engine is responsible for executing high-fidelity simulations of quantum channel and key exchange protocols. It uses a message broker to process tasks asynchronously, allowing it to model multiple QKD links in parallel while ensuring that link-level operations are executed in the correct sequence.
ETSI GS QKD 014 API
This is a standardized application programming interface that all emulated nodes expose. It allows client applications to interact with the simulated network exactly as they would with real QKD hardware, ensuring seamless compatibility across different simulation setups.

Terminology

Summary

The gist: Quditto is an automated open-access emulation platform that combines high-fidelity quantum-channel modeling with a standardized key-delivery API, enabling users to interact with an emulated network exactly as they would with real QKD hardware.

State of the Art and Motivation

Existing simulation tools offer diverse perspectives on the behavior of Quantum Key Distribution Networks (QKDNs), but none provide a complete, standardscompliant emulation framework that simultaneously achieves high-fidelity modeling, support for multi-device topologies, and compatibility with commercial QKD hardware APIs<ref:2512.15408#pg3>. Specifically, existing works either focus on accurate quantum-physical modeling or rely on physically simplified abstractions to enable scalable network-level studies<ref:2512.15408#pg8>. The gap motivates the development of a new research platform that combines all these features, allowing users to deploy an emulated, fully distributed, and standards-aligned QKDN<ref:2512.15408#pg4>.

Quditto Design and Components

Quditto is designed as a highly modular platform consisting of three main components: the Quditto orchestrator, the Quditto modeling engine, and the Quditto nodes<ref:2512.15408#pg4>. From the user's perspective, the resulting distributed QKDN behaves like a real QKD network as client applications communicate in real-time with network nodes via a standardized API<ref:2512.15408#pg4>.

Quditto is not a simulation platform; it coordinates the automatic deployment of a realistic QKDN distributed across classical equipment and cloud infrastructures.

All emulated nodes expose the ETSI GS QKD 014-compliant API, allowing seamless interaction with the network exactly as one would with real QKD hardware.

The three main components are detailed as follows:

  1. Quditto Nodes: These handle application requests for cryptographic material and offer a standardized API<ref:2512.15408#pg4>. They internally forward each request to the modeling engine via a Pub/Sub protocol<ref:2512.15408#pg4>.

  2. Quditto Modeling Engine: This consists of a message-broker handler and a modeling core that executes high-fidelity quantum channel and key exchange protocol implementations<ref:2512.15408#pg4>. It operates as an asynchronous event-driven service, processing tasks for different QKD links in parallel but enforcing linklevel serialization<ref:2512.15408#pg4>.

  3. Quditto Orchestrator: This component takes the network description and handles its deployment and configuration<ref:2512.15408#pg4>. It automatically provisions each target device with the required software stack, sets up the message broker, and launches all necessary processes to produce a fully operational, standard-compliant network<ref:2512.15408#pg4>.

Implementation Details

Quditto is built as a Python-based platform published under an open-source license<ref:2512.15408#pg5>. The orchestrator package uses Ansible to configure pre-existing devices with Internet connectivity, installing the Quditto node package on every node and the emulation core package on the designated engine device<ref:2512.15408#pg5>.

The Quditto Node package implements two parallel processes:

The first process handles all interactions with the modeling engine performed through the broker implemented using the open-source RabbitMQ software.

**The second process hosts an HTTP server that provides the ETSI GS QKD 014 API [6]. **

The Quditto quantum-behavior modeling engine package is comprised of two main parts: a message-broker handler and a modeling core built on top of NetSquid quantum simulator<ref:2512.15408#pg5>. By default, the engine features two QKD protocol implementations based on the BB84 scheme: BB84 with Eve, which enables the placement of an eavesdropper performing an intercept–resend attack at any point along the quantum channel, and Extended BB84 [14], [15], which incorporates user-configurable parameters to model realistic behavior and imperfections<ref:2512.15408#pg5>.

Validation Results

The validation experiments demonstrate Quditto's capabilities in automated deployment and functional testing<ref:2512.15408#pg7>.

**Quditto deploys faster (or similarly, in the case of 10) than even a 2-node network in our previous service [3]. **

**The Quijote-Aquiles link exhibits the highest times and the steepest growth rate. **

In a partially adversarial QKD environment, when an eavesdropper intercepts 30% of the qubits on the Quijote–Aquiles link, the exchange yields a Quantum Bit Error Rate (QBER) of 0.1484, which exceeds the secure threshold of 0.11 for the BB84 protocol<ref:2512.15408#pg8>. Furthermore, Quditto supports complex key management schemes by enabling a Key Management Entity (KME) to orchestrate a key relay via a trusted node, allowing external components to interact seamlessly with the nodes<ref:2512.15408#pg8>.

Conclusion and Future Directions

Quditto has been presented as a comprehensive emulation platform that combines high-fidelity quantum-channel modeling with support for multi-device topologies and the implementation of the ETSI GS QKD 014 API<ref:2512.15408#pg7>. The work suggests two main lines of research: first, incorporating additional QKD protocols along with their reconciliation and privacy amplification modules to expand the range of experiments, and second, supporting hybrid deployments by directly interfacing with quantum hardware for hardware-in-the-loop testing<ref:2512.15408#pg7>. The platform's modular design allows developers to integrate different implementations of quantum devices, protocols, or management features<ref:2512.15408#pg4>.

Improvements for AI systems

  1. textbfImprove QKD Network Emulation Fidelity with High-Fidelity Modeling Integration: The system can now emulate a distributed QKDN that closely mirrors physical hardware by combining high-fidelity modeling with an ETSI standard-compliant Application Programming Interface (API). This allows users to interact with emulated nodes in real time in the same way they would with physical QKD hardware.

  2. textbfEnhance Versatility through Modular Architecture: The platform supports flexibility by allowing users to integrate different quantum-behavior modeling engines and adopt alternative QKD protocol implementations, whether based on NetSquid or any other modeling platform. This means the system can be tailored for various quantum technologies beyond the default implementation.

  3. textbfEnable Real-Time Interactive Key Management: The system facilitates complex key management schemes by supporting trusted node relays for end-to-end exchanges between non-adjacent network endpoints. This capability allows external components, such as a Key Management Entity (KME), to orchestrate key relays using the standardized API.

  4. textbfSupport Realistic Physical Scenarios: The system can model more physically realistic QKD scenarios by incorporating effects such as channel attenuation, photon loss, and decoherence, moving beyond basic models like BB84 with Eve. This enables testing under conditions that include fibre photon losses and device imperfections like detector inefficiencies and dark counts.

  5. textbfImprove Automated Deployment Efficiency: The system can perform automated and scalable deployment of emulated QKDNs with minimal user effort, as demonstrated by the orchestrator's efficiency gains. This means a user can define a QKDN via YAML files, and the orchestrator will automatically install and configure all required software on the target equipment.

Sources

Related papers