Frequently Asked Questions
“Not everything that is faced can be changed, but nothing can be changed until it is faced.”― James Baldwin
Quantum cryptography, more specifically quantum key distribution or QKD, is a cryptographic tool that enables the establishment of symmetric keys through an authenticated but untrusted channel that permits the transmission of quantum signals. Quantum channels include optical fibres or line of sight free-space transmissions.
A Quantum Delivery Network (QDN) is a software overlay that runs on top of modern high-speed network and helps to integrate quantum-safe technologies such as QKD to protect the network from quantum threats. A QDN enables two parties to privately make and share secret cryptographic keys that are later used for conventional network security operations like VPN, SSL, Layer-1 and Layer-2 type secure network connections. This offers a defense-in-depth security approach to protect the network from quantum computation attacks. A QDN ensures that quantum keys, derived from QKD links are available to users and services throughout a network accounting for security policy and network capacity concerns.
No. A QDN requires QKD devices to function in a secure manner. However, a QDN can simulate QKD devices in software for proof-of-concept or demonstration systems to prove out a network.
The QDN ensures that quantum keys derived from QKD technologies are available to users and services throughout a network accounting for security policy and network capacity concerns. A modern high-speed network’s data rates are measured in gigabits per second (Gbps) in contrast to a QKD-linked network with key generation rates measured in kilobits per second (Kbps). A small amount of quantum key can be used to protect a large amount of modern high-speed network data traffic but supply and demand of quantum keys need to be carefully managed because highspeed data traffic is not uniform, it has peaks and valleys where a surge in data traffic can quickly exhaust keying material produced by quantum links if not properly managed.
The main advantage of QKD is that it is not susceptible to mathematical cryptanalysis. QKD is especially valuable for establishing keys that require a long shelf-life or for protecting critical systems where there is value in mitigating the risk that post-quantum/quantum-resistant/mathematical key agreement is cryptanalyzed.
QKD vendors are standardizing on the GS QKD 014 - V1.1.1 - Quantum Key Distribution (QKD); Protocol and data format of REST-based key delivery API (etsi.org) interface. As a result, there is less variability between QKD vendors compared to a few years ago. The interface is a simple key request API consisting of two main methods – [Get Key(s)] and [Get Key(s) with Key ID(s)]. The initiator requests keys of a given size using [Get Key(s)] and is returned a corresponding list of key id/value pairs. The initiator then sends the key IDs to the target endpoint, application specific and outside the QKD device interface, and the target uses these Key IDs to request the corresponding key values using [Get Key(s) with Key ID(s)]. A Status method is also defined in ETSI-014 to obtain settings from the QKD device. There are some optional parameters as part of the key request, mainly key metadata, that could lead to differences in vendor implementations. As optional items they should not be required though. BasejumpQDN implements a layer of software abstraction called the Quantum Link Layer (QLL) that allows the software to isolate any differences in QKD vendor’s implementation and behavior. This also allows BasejumpQDN to support many different QKD vendors devices and take advantage of any optional items a vendor has implemented in the ETSI-014 implementation.
Key generation rates – BasejumpQDN can not increase the rate at which keys are generated by third-party QKD devices, but it can ensure that all keys are utilized for the benefit of the network. By increasing utilization and decreasing the number of keys that expire/age out, this decreases cost-per-key metrics.
Distance – BasejumpQDN can increase the reach of the overall QKD network by implementing a trusted node scheme.
Latency – BasejumpQDN limits latency of QKD key requests by applications and devices that it is serving. This is achieved this by anticipating, storing, and queuing up enough QKD key material local to the requesting applications/devices so that an application/device does not need to wait for a lower level QKD protocol to first generate key material. This latency-saving step is why BasejumpQDN uses demand and capacity estimates in routing calculations for the network.
BasejumpQDN optimizes overall satisfaction of demand in the network through linear programming techniques. The routing solution calculates a solution to maximize the satisfaction of the demand pairings in the network given the current link capacities. The key swapping routes reflect this demand optimization, so longer routes may be chosen to better address overall network demand. The optimization populates key pools between node pairs proactively so that client key requests can be filled immediately instead of being subject to the latency that would be otherwise be required for an interactive key swap to occur.
Reducing QKD Device Capex – evolutionQ uses an up to 10x reduction in costs in our promotional literature when describing TCO benefits. The more complex answer is that BasejumpQDN reduces the number of QKD devices required in the network from “N choose 2” down to (N-1)*2. For instance, a network with 40 nodes would require 40 choose 2 = 780 QKD devices without our software (or another type of trusted node solution), compared to (40 -1) *2 = 78 QKD devices with BasejumpQDN. The reasoning for this is because if a QKD network does not implement trusted nodes, then every node in the network needs to be directly connected to every other node to form a “complete graph”. When trusted nodes are used then the network can instead form a “connected graph”, which requires less connections and allows the network to stretch out over longer distances.