Why Latency Matters for QKD Key Delivery
The latency of key delivery in a QKD system is a distinct metric from the latency of the encrypted data channel itself. In a typical QKD deployment, keys are pre-distributed and stored in buffers at each endpoint. When an application needs to establish an encrypted session, it requests a key from the local key management server, which draws from the buffer of pre-distributed QKD key material. The relevant latency is the time from key request to key availability at the application layer.
This is different from TLS handshake latency, where the key exchange happens inline at session establishment time. In QKD, the "key exchange" (the photon-level quantum key generation) happens asynchronously during satellite pass windows, separate from the application session establishment. The key delivery latency is the time for a pre-generated key to be moved from the buffer to the requesting endpoint, which is primarily a function of key management server performance and local network latency, not quantum optical physics.
The practical question is: can QKD key delivery happen fast enough that it does not add perceptible overhead to session establishment for the applications being protected? For interactive user-facing applications, the answer depends on the key delivery latency relative to the total session establishment time. For batch or background processes, latency is less critical than throughput and availability.
The Bengaluru Pilot Setup
Our Bengaluru pilot deployed four ground station nodes across the metropolitan area, chosen to provide coverage diversity: sites in the electronic city technology corridor, the northern business district, the university area in the west, and the central business district near Palace Road. Each site has a ground station receiver connected to a key management server on a dedicated fiber backhaul.
The key management servers run our key distribution software, which manages the key buffer at each node and handles key routing requests from application endpoints. The application endpoints in the pilot are test integration points running a REST API client that requests keys from the local key management server and measures the round-trip latency from request to key receipt.
Measurement methodology: we instrumented the key request path with microsecond-precision timestamps at five points: application sends request, request arrives at key management server, key management server generates response, response arrives at application, application processes key material. The five-point timestamps allow us to separate transport latency from key management processing time and identify where latency is concentrated.
What the Numbers Showed
Across roughly 180,000 key delivery events measured over a 6-week period in the pilot, the median end-to-end key delivery latency was 1.4ms with a 95th percentile of 1.9ms and a 99th percentile of 3.8ms. The sub-2ms headline figure refers to the median, which is the representative value for steady-state operation with a healthy key buffer.
The latency distribution has two distinct modes. The fast mode (90 to 95 percent of requests) represents key requests served from a full or near-full local buffer: the key management server retrieves key material from its in-memory buffer, performs access control validation, and returns the key. This path has consistent latency in the 0.8 to 1.6ms range. The slow mode (5 to 10 percent of requests) represents cases where the local buffer was depleted and the request required routing to a different node or waiting for buffer replenishment. This path shows latency in the 3 to 15ms range depending on the routing topology.
The slow mode tail matters for two reasons. First, it represents real application-visible latency in the cases where buffer management has not adequately anticipated demand. Second, the frequency of slow-mode events is directly controllable through buffer sizing and routing policy: our adaptive routing layer has reduced the slow-mode event rate from 18 percent in early pilot phases to below 6 percent in current operation by better anticipating demand patterns and pre-positioning key material.
Latency Sources and What Can Be Improved
Breaking down the latency into components is useful for understanding what the limiting factors are and where optimization has headroom.
Transport latency (application to key management server, via the site's local network) accounts for roughly 0.3 to 0.5ms in our setup. This is dominated by the fiber link latency within each site. In a production deployment where the application server and key management server are co-located in the same rack or data center, this component drops below 0.1ms.
Key management server processing time accounts for 0.6 to 0.8ms in the fast path. This includes access control validation (checking that the requesting endpoint is authorized to receive the requested key class), buffer lookup, key material retrieval, and response serialization. This component is primarily software performance and scales with server hardware; our current implementation runs on standard server hardware without specialized cryptographic acceleration.
Key routing and delivery for inter-node requests accounts for the remaining latency in the slow path. This includes the time to query the routing layer for which node has the requested key material, the inter-node network latency (10 to 40ms for cross-city hops in Bengaluru), and the receiving-node buffer lookup. The large variance in the slow path reflects the variance in inter-node round-trip latency across the four sites.
Application Fit: Which Use Cases Work at This Latency
Sub-2ms median key delivery fits cleanly within the latency budget of most application session establishment patterns. TLS 1.3 handshakes take 1 to 3ms on a local network before the key exchange computation is included. Adding a 1.4ms key delivery step is within the noise for most connection establishment patterns.
Interbank settlement traffic is the application category we focused on in the pilot. NEFT and RTGS settlement messages have end-to-end latency requirements on the order of seconds (for NEFT, 30 to 120 minute batches; for RTGS, intraday real-time). Key delivery at 1 to 2ms is negligible in the context of these latency budgets. What matters is key availability, not key delivery latency: if the buffer is empty, the settlement message cannot be encrypted with a QKD key, regardless of how fast the delivery would be once a key is available. Buffer management and availability are the operational metrics that matter most for this application class.
High-frequency financial applications with sub-100ms end-to-end latency requirements require more careful analysis. If the key delivery path traverses a slow-mode event with 10 to 15ms latency, it can become a material fraction of the total budget. These applications need either sufficiently large key buffers that slow-mode events are vanishingly rare, or a fallback mechanism that allows them to use ML-KEM-derived key material when QKD buffer levels are low.
Key Generation Rate and Buffer Sizing
The latency measurements are only meaningful in the context of the key generation rate, which determines how fast depleted buffers can be replenished. Our pilot measured key generation rates during satellite pass windows in the range of 1 to 10 kilobits per second of final extracted key material, varying with link quality. AES-256 keys are 256 bits, so that translates to roughly 4 to 40 thousand keys per second of pass window, or 2 to 20 million keys per day across expected pass windows per ground station.
For a pilot-scale deployment serving a handful of application endpoints with moderate key consumption rates, this generation rate is more than adequate to maintain buffers. As the number of application endpoints and the key consumption rate scale up, buffer sizing and generation rate become binding constraints. Our pilot is not yet at a scale where generation rate is a bottleneck, but the architecture is designed to scale by adding ground stations and utilizing additional satellite pass capacity, rather than by changing the fundamental key distribution model.
