Quantum Keys for Drones: The Waiting-Room Tax That Finite-Key QKD Imposes on UAV Edge Computing

First paper to quantify how finite-key QKD's accept/reject lottery inflates UAV task completion time from 10s to 29s — and maps the razor-thin operating window where it works at all.

Imagine you run a food truck, but every morning you have to spin a roulette wheel to see if you get a health permit. Most days you do, but some days you don't — and on those days you burn propane keeping the fryer hot while you re-apply. Now imagine the permit office also charges you a fee from your existing permits every time you apply, so each failed attempt eats into your stockpile. That's the core mechanism here: a UAV trying to do secure edge computing must wait for quantum key distribution (QKD) to produce a valid key block, and each attempt can fail, costing time, hover energy, and authentication-key reserves. The committed claim: for a stationary UAV serving two ground gateways via finite-key decoy-state BB84, the cost of waiting for fresh quantum keys inflates the 95th-percentile task completion time from 10.37 seconds (pre-shared keys) to 28.65 seconds (fresh QKD keys) at 26 dB optical loss. This is a systems-engineering result, not a cryptographic one. The paper doesn't improve BB84 or invent a new protocol — it builds a count-level Monte Carlo simulator (validated by a semi-analytic model) that chains together key generation, acceptance/rejection, authentication hashing, upload, compute, and download into an end-to-end latency budget. The finding is that the probabilistic nature of finite-key acceptance creates a bottleneck that scalar key-rate models completely miss. The architecture is straightforward simulation engineering. A Monte Carlo model draws photon-count outcomes for each BB84 block, applies finite-key security bounds to accept or reject, deducts authentication-key costs from a running ledger, and feeds surviving keys into a task-completion pipeline. A semi-analytic companion model confirms the Monte Carlo results. The compute property being leaned on is brute-force sampling of the accept/reject distribution — no optimization loop, no machine learning, no variational anything. This is classical simulation of a quantum protocol's operational overhead. The most operationally useful result is the 'operating window' analysis. The pulse budget (how many photons you send per attempt) is bounded below by the authentication-key replenishment floor — send too few pulses and you can't even recover the authentication keys you spent — and above by the deadline. At a 35-second deadline, the largest tolerable loss is 27 dB at 1% misalignment, 22 dB at 2%, and at 3% misalignment no tested configuration has a viable window at all. This maps directly to a link-budget constraint for any real deployment: your drone-to-ground channel must stay below these loss thresholds or the system simply cannot close. Integrity is mixed. The validation is self-contained: Monte Carlo confirmed by the authors' own semi-analytic model, with held-out trial confidence bounds of 96.9–97.3%. The authentication hashing cost is handled via a 'proxy benchmark' described as near-zero, and a stress reference that charges hashing in full. There's no independent replication, no hardware experiment, and the acquisition probability (whether the drone even establishes optical contact) is assumed, not measured. The paper is honest about these limitations, but the entire result chain sits inside a simulation bubble. The milestone lens is sobering. The paper demonstrates that finite-key QKD imposes a real and quantifiable systems tax, but the operating window is extremely narrow. A small rise in error rate or loss pushes deadline probability well below target and drains authentication keys. The next concrete milestone would be a hardware demonstration — an actual UAV-to-ground QKD link closing the loop on the end-to-end latency budget predicted here. The gap between simulation and field experiment is where most UAV-QKD work stalls, and this paper doesn't close it. The obvious experiment the authors didn't run: a moving UAV. The entire analysis assumes a stationary (hovering) drone with a fixed channel. Real UAV missions involve flight, pointing jitter, and time-varying loss. The paper's framework could in principle handle time-varying channels, but the computational cost would multiply and the operating window would almost certainly shrink further. The honest read: they scoped tightly to get clean results on the stationary case, and the mobile case is the next paper.