Modeling the wait for fresh quantum keys in drone-based computing

Quantum key distribution (QKD) generates shared secret keys using quantum signals. But it cannot guarantee that every attempt will yield a usable key. In a finite-key protocol, users collect a fixed batch of signals, test the results, and either release a predetermined amount of key material or abort. When a computing task must wait for that decision, key generation becomes part of the service’s schedule.

A new preprint by Dang H. Le, Ban Q. Tran and Susan Mengel explores this issue in a modeled system: a stationary, trusted drone serves two ground gateways in sequence. Each gateway has a task that requires fresh keys. The authors estimate completion time and hovering energy, and examine whether enough authentication key remains to support future QKD attempts while meeting a deadline. This is a simulation study, not a demonstration with a working drone service.

Modeling a key before computation

The researchers simulate one finite-key, decoy-state BB84 attempt for each gateway. BB84 is a widely used QKD protocol; decoy states help estimate which detected signals can contribute to a secure key. The protocol settings are fixed in advance. If the observed counts and error tests pass, the attempt releases a predetermined key length; otherwise, it aborts. Even a failed attempt takes time and consumes authentication-key material used to verify messages exchanged during QKD.

The model connects those outcomes to protected data uploads, computation and downloads. The authors use a count-level Monte Carlo simulation to generate possible detection counts and other modeled outcomes, then compare it with a semi-analytic calculation. Their close agreement checks the calculation against the simulation; it does not show that the assumptions accurately represent a real deployment.

The scenario is specific: two gateways share one optical receiver on the drone, and tasks run one after another. In the headline case, the model assumes 26 decibels of effective optical loss, a 99% probability of successful acquisition, and 1% optical misalignment. Other inputs, including radio conditions and processing capacity, form part of a composite benchmark rather than measurements of one calibrated platform.

A pulse-budget window—with a policy caveat

At 26 dB loss, the modeled 95th-percentile completion time is 10.37 seconds when application keys are already available. Requiring fresh keys raises it to 28.65 seconds in the authors’ near-zero hashing-cost case. Hover energy grows with time because the modeled drone remains aloft through key generation and task execution.

The number of optical pulses sent in each attempt affects both service timing and, under the paper’s pool policy, the replenishment of authentication keys. Too few pulses can yield too little new key material to replace the authentication bits spent on attempts. Too many take longer to collect and can push the task beyond its deadline. This creates a feasible range in the modeled policy—but the lower bound is not universal. It is a sufficient condition for keeping a persistent authentication pool from shrinking; refilling the pool when the drone lands could remove that requirement.

For a 35-second deadline, the largest tested optical loss with a non-empty range is 27 dB at 1% misalignment and 22 dB at 2%. At 3%, none of the tested settings has a range. For selected configurations, held-out simulation trials give simultaneous lower confidence bounds of 96.9–97.3% for meeting the deadline, conditional on the assumed acquisition probability. Those bounds describe statistical uncertainty within the model, not measured reliability in flight.

The hashing assumption matters. The headline result treats hashing as nearly cost-free, motivated by measurements using Poly1305 and GHASH as proxies. Those proxies do not calibrate either the specified authentication method or its execution on a drone. In a stress case that charges hashing in full, the modeled range narrows. The simulations also show that small increases in error or loss can sharply reduce key acceptance and drain the authentication pool. That can disrupt service without changing the protocol’s stated security parameter: secrecy guarantees and availability are different questions.

What remains uncertain

The paper evaluates service availability and scheduling; it does not offer a new QKD security proof. Its security claims rely on an existing finite-key proof and assumptions including trusted devices, securely provisioned authentication keys and successful error correction. The authors do not benchmark the specified message authenticator or a decoder. Their disturbance tests cover selected scenarios, not every possible adaptive attack, and assume acquisition success is independent of an adversary.

The authors note that 1% misalignment is optimistic compared with drone-link measurements they cite. The model also excludes factors such as device side channels and radio jamming. Its estimates should therefore be read as conditional results for a particular modeled setup, not predictions for all UAV services. The preprint’s central practical point is that when fresh QKD keys sit on a task’s critical path, finite-block acceptance, processing, deadlines and any authentication-pool policy need to be considered together; an average key rate alone cannot show whether a task will finish on time.