Quantum Key Pools (QKPs)
- Quantum Key Pools (QKPs) are managed reservoirs of QKD-derived keys paired with systems that enforce policies such as one-time use and expiration.
- They decouple key generation from consumption, enabling efficient key distribution in pairwise, networked, and enterprise-scale architectures.
- Recent studies emphasize QKPs' roles in secure key storage, optimized allocation, and resilience against physical-layer and routing attacks.
Searching arXiv for papers on Quantum Key Pools and closely related QKD key management/storage. Quantum Key Pools (QKPs) are managed reservoirs of secret key material generated through quantum mechanisms and organized for later cryptographic use. In the most direct formulation, a QKP is a set of keys
whose elements are bit strings produced by a QKD protocol and known only to legitimate parties, together with a management system that adds keys as sessions complete, marks them as unused, in use, or retired, and enforces policies such as one-time use, expiration, or application binding (Goel, 2010). In networked formulations, QKPs act as key caches at nodes, storing pre-distributed keys for future use and thereby decoupling key generation from key consumption over time (Li et al., 14 Aug 2025). In enterprise and multi-site QKD architectures, they form the operative interface between scarce QKD-generated key material and higher-level systems such as TLS, IPsec, VPNs, and one-time-pad channels (Tysowski et al., 2017, Dervisevic et al., 2024, Dervisevic et al., 2024).
1. Definition and conceptual scope
The term Quantum Key Pool is not uniformly used across the literature. Some works define it explicitly as a managed pool of QKD-derived keys, while others describe equivalent structures under names such as key stores, buffers, repositories, key banks, or caches (Goel, 2010, Dervisevic et al., 2024). The common abstraction is stable: quantum mechanisms generate secret bits; a classical management layer stores, indexes, synchronizes, and allocates those bits to applications.
In pairwise QKD deployments, a QKP is naturally associated with an endpoint pair. Repeated QKD sessions produce a sequence of final keys , and the pool records metadata such as creation time, origin, intended usage, and lifecycle state (Goel, 2010). In networked settings, the abstraction becomes path-aware or node-pair-aware. The RWA-MAR model treats QKPs as key caches at each node, storing pre-distributed keys for future use, and introduces a state variable for the quantity of stored keys associated with a path or node pair at timeslot (Li et al., 14 Aug 2025).
The concept also generalizes beyond pairwise keys. In layered quantum key distribution, the key resource is indexed by user subsets rather than by a single endpoint pair. A layered key structure is written as
where each subset in defines one shared key. In that setting, a multi-user QKP can be modeled as
with each available only to the users in (Pivoluska et al., 2017). This makes QKPs not merely storage objects, but access-structured cryptographic resources.
A further conceptual broadening appears in the qPKE literature, where public keys themselves are quantum states and may exist in multiple prepared copies. That work does not describe QKPs directly, but it provides a formal vocabulary for pools of quantum keys that are consumable, reusable, or usage-tracked under no-cloning and measurement-disturbance constraints (Barooti et al., 2023). This suggests that QKPs can denote either reservoirs of symmetric secret keys derived from QKD or, in a wider quantum-cryptographic sense, managed collections of quantum key states.
2. Generation of pool material from quantum protocols
The canonical source of QKP material is BB84-style QKD. In the polarization-based formulation, Alice encodes random bits into four non-orthogonal states,
0
with
1
Bob measures in randomly chosen bases; after public basis announcement, the parties discard mismatched positions and obtain a raw key. If error tests pass, privacy amplification compresses the raw key into a shorter final key suitable for pool insertion (Goel, 2010).
A QKP turns that episodic protocol into a service. The BB84 stream is segmented into fixed-length pool elements,
2
and each element is inserted with metadata describing origin, time, expected security level, and intended role such as one-time pad, session key, or MAC key (Goel, 2010). The central operational distinction is therefore between generation and consumption: QKD continuously fills the pool, while applications draw from it on demand.
Other quantum protocols can also populate QKPs. The paper on quantum data locking gives a high-rate secret-key-generation mechanism over memoryless qudit channels in which, under a bounded-coherence-time assumption for Eve, the net secret key rate is
3
and for unitarily covariant channels,
4
bits per channel use (Lupo et al., 2014). In that construction, a small seed key is recycled while the remaining generated secret bits are added to the pool. The result is a high-throughput, but conditional, QKP-filling mechanism.
Layered QKD supplies a different kind of pool material: simultaneous keys for multiple user subsets. For a layered structure 5, each use of the multipartite high-dimensional state 6 can produce bits for several layers at once, and in the pure tensor-product construction each layer can ideally reach 7 bit per use of 8 (Pivoluska et al., 2017). This is a direct physical realization of multi-layer QKPs.
Unconventional classical post-processing can also alter the shape of pool output. The random-seed protocol that keeps the quantum stage identical to BB84 but changes the classical stage claims that, in perfect conditions, Alice and Bob share four secret and secure keys of length 9,
0
after two BB84-style transmissions and a structured classical reconciliation based on a public seed 1 and a selector function 2 (Serna, 2013). A plausible implication is that QKPs need not always be populated by a single final key stream; some protocols present batched or multi-key outputs per session.
3. Architectural realizations
QKPs appear in markedly different architectural forms depending on whether the system is pairwise, networked, or enterprise-scale.
| Context | Pool structure | Distinctive feature |
|---|---|---|
| Pairwise BB84 deployment | 3 | Lifecycle states and policy enforcement |
| RWA-MAR QKD network | Node-pair/path cache 4 | Auxiliary links backed by stored keys |
| Enterprise multi-site system | Persistent KMS quantum key pool | Host-facing session-key service |
| QKD key-storage engineering | Q-Buffer, S-Buffers, deques | Size-aware supply optimization |
| Layered QKD network | Subset-indexed pools 5 | Concurrent group and pairwise keys |
| Surveyed trusted-repeater systems | Stores, buffers, key banks | Relay, synchronization, and QoS |
In enterprise-scale architectures, the most detailed implementation is the four-layer model comprising Host Layer, Key Management Service (KMS) Layer, QKD Network Layer (QNL), and QKD Link Layer (QLL). The KMS maintains a persistent quantum key pool per site pair, reads quantum-generated key material from the network layer, synchronizes pool state with the peer site, and constructs host session keys according to policy on key length, lifetime, and security class (Tysowski et al., 2017). Higher-level applications do not interact with the quantum layer directly; they request ordinary symmetric keys, while the KMS maps those requests onto specific positions in the synchronized pool.
The survey literature shows the same pattern under varied terminology. SECOQC/Toshiba employs pickup stores, a common store, and in/out buffers; NEC distinguishes quantum key pools 6 for local keys from logical key pools 7 for global keys; NIST uses a secret key store and per-application FIFO queues; Magiq uses persistent storage 8 and per-application key storages 9; Quantum Canada combines temporary network-layer buffers with KMS-layer pools; Cisco stores QKD keys in an internal SQLite database (Dervisevic et al., 2024). The structural commonality is more important than the naming difference.
In routing-aware network optimization, QKPs are lifted into the graph model itself. The RWA-MAR framework defines a physical directed graph 0 and a fully connected auxiliary graph 1. Auxiliary links can represent direct quantum routes, trusted relay, optical bypass, or QKP-backed logical connectivity. Stored keys contribute an additive term 2 to the effective key rate of a logical link, and the key-balance constraint
3
treats the pool as an explicit time-evolving optimization resource (Li et al., 14 Aug 2025).
4. Storage, allocation, and performance engineering
Practical QKPs are shaped as much by storage design as by quantum protocol choice. The key-storage study identifies three main designs that are, in effect, three QKP organizations: a single common storage, encryption/decryption storages with a common Q-Buffer, and application-oriented storages, culminating in a novel design based on application-shared deques keyed by requested key size (Dervisevic et al., 2024).
The single common storage design is operationally problematic because multiple applications can collide on the same key material. In the reported simulations, key-access collision percentage is high when residual key count is low; when residual keys exceed 1000, collision percentage becomes negligible but remains non-zero. With increasing numbers of concurrent applications, the relative collision percentage rises even when QKD rate is scaled to demand (Dervisevic et al., 2024). For a QKP, this means that naive pooling without purpose separation or reservation logic can waste scarce quantum keys and, under one-time-pad semantics, compromise correctness of usage.
The second design separates a non-volatile common Q-Buffer from volatile encryption and decryption S-Buffers, implemented as hash tables. Here, keys from QKD are first stored in a default size, then moved into purpose-specific pools, and finally merged or split to satisfy application requests. CPU time for supply creation increases with requested key size and with the number of keys per query, while increasing the default key size reduces average CPU time because fewer merge operations are needed (Dervisevic et al., 2024). This is a flexible but transformation-heavy QKP.
The third design, and the strongest performer in that study, uses application-shared deques keyed by key size. Keys are preformatted once when the deque is filled; supply operations then reduce largely to deque pop operations plus UUID assignment and peer synchronization. In the reported experiments, average CPU time is almost constant across key sizes for a fixed number of keys per request, and is independent of the default QKD-layer key size. With about 4 applications, about 5 deques are created on average, showing that multiple applications can share size-class pools efficiently (Dervisevic et al., 2024).
Capacity engineering in networked QKPs depends on both cryptographic policy and physical key rates. The RWA-MAR paper estimates minimum required QKP capacity per node pair for a one-hour stage as about 6 bits, using AES-256 in CBC mode, the assumption that one AES-256 key can securely encrypt up to 7 blocks, and a 8-channel fiber carrying 9 Tb/s per channel, which implies key rotation every 0 seconds (Li et al., 14 Aug 2025). The same work gives indicative achievable key rates from realistic models: 1 kb/s at 2 km, 3 kb/s at 4 km, 5 kb/s at 6 km, 7 kb/s at 8 km, and 9 kb/s at 0 km; with optical bypass, rates decrease by 1 per crossed node (Li et al., 14 Aug 2025). These figures make clear that QKPs exist to absorb severe mismatches between key-generation rate and application data rate.
5. Security properties, resilience, and contested security models
For conventional QKD-derived pools, the security basis is standard: disturbance reveals eavesdropping, and privacy amplification removes residual leakage. In BB84, a full intercept-resend attack yields a quantum bit error rate of approximately 2; if the observed QBER exceeds threshold, the key is discarded rather than admitted to the pool. Only privacy-amplified keys that pass error tests are stored, and the resulting QKP inherits unconditional or information-theoretic security against adversaries with unlimited computing power (Goel, 2010).
In networked settings, QKPs also serve as resilience mechanisms. Within RWA-MAR, requests served purely from QKP have 3 because they do not traverse any physical quantum link in that timeslot and therefore cannot be disrupted by a link-level physical-layer attack. In the NSF topology with 4 nodes and 5 links, OB/OBTR0 architectures with QKP and heuristic routing achieve about 6 lower maxNAR than the baseline shortest-path routing; TR yields the lowest maxNAR and avgNAR but can exhaust modules after about 7 requests; OBTR80 yields maxNAR reductions of 8 versus OBTR0 and 9 versus OB-only (Li et al., 14 Aug 2025). QKPs are therefore not merely passive stores; they are active mitigations against jamming-induced attack radius.
A common misconception is that any “quantum” pool automatically carries the same security guarantees. The literature is more heterogeneous. Quantum data locking can populate a pool at rates approaching classical capacity, but its security depends critically on a bounded coherence time for Eve’s quantum memory. If that assumption fails, the accessible-information criterion is no longer composable in the intended way, and the resulting pool is not unconditionally secure in the standard QKD sense (Lupo et al., 2014). By contrast, qPKE with quantum public keys provably cannot achieve information-theoretic security at all; computational assumptions are necessary, and no qPKE scheme can provide unconditional security (Barooti et al., 2023).
A different challenge to the conventional picture is probability key distribution, which claims unconditionally secure key distribution without any quantum channel between users by using a provable quantum one-way function on coherent-state phases and a random information negotiation mechanism (Yin, 2024). In that framework, non-local entangled states are generated, identified, and measured only in an equivalent virtual protocol, and the claimed net secret key rate is about 0 Mbps under the stated parameters. This does not refute QKD-based QKPs, but it does widen the field of constructions that may be interpreted as QKP-filling mechanisms.
6. Applications, multi-user extensions, and future directions
The application range associated with QKPs is broad. Early QKD literature emphasizes banks, insurance, brokerages firms, financial institutions, e-commerce, and defense and security (Goel, 2010). Enterprise engineering work makes that concrete by defining host-facing key services for arbitrary computing hosts on one site to establish multiple secure communication sessions with hosts of another site through a synchronized pool-backed KMS (Tysowski et al., 2017). Surveyed deployments connect QKPs to VPNs, TLS, MACsec, Kerberos, IKEv2, and one-time-pad services (Dervisevic et al., 2024).
Multi-user generalization is particularly developed in layered QKD. Because any layered key structure 1 can be implemented by a suitable multipartite high-dimensional state, a QKP need not be a mere pairwise resource; it can simultaneously maintain global broadcast keys, subgroup keys, and pairwise keys, all indexed by overlapping user subsets (Pivoluska et al., 2017). GHZ-based master-key-secured QKD adds another perspective: a reservoir of multipartite GHZ states can be regarded as a pool of latent correlations, where secure key and master key are activated by designated measurements and classical announcements (Qureshi et al., 2013).
Some proposals enlarge QKP throughput by altering the surrounding key-growing assumptions rather than the quantum source. The random-seed protocol claims four full-length keys per session under ideal conditions (Serna, 2013). Beacon-based key growing uses a pre-shared master key 2, public randomness beacon pulses 3, and a quantum-safe function 4 to derive session keys
5
which is quantum safe but not information-theoretic (Ling et al., 2017). These alternatives suggest a taxonomy in which QKPs may be rooted in QKD, hybridized with computational key-growing, or embedded in broader key-management systems.
The main open problems are organizational as much as physical. The survey literature highlights the need for a standardized QKD–KM interface, more systematic study of key storage designs, stronger QoS and multi-tenant resource-sharing mechanisms, standardized KM–KM interfaces for relay and interoperability, formal security models for key management itself, and machine-learning-assisted adaptation of key unit lengths and allocation policies (Dervisevic et al., 2024). Earlier work also emphasizes physical constraints: photon keys can travel only between directly connected computers through fiber-optic lines, photons degenerate over long distances, and the technology remains expensive (Goel, 2010). A plausible implication is that the long-term importance of QKPs will depend less on the abstract idea of quantum-generated keys than on whether storage, synchronization, routing, and policy layers can convert limited quantum resources into dependable cryptographic infrastructure.