Frequently Asked Questions

The quantum threat in cybersecurity refers to the risk that powerful quantum computers could break many of the cryptographic systems and encryption algorithms currently used to protect digital data and communications, including those in financial payment systems, the Internet, digital signatures, e-health data and cloud computing.

A Cryptographically Relevant Quantum Computer (CRQC) is a quantum computer that is powerful enough to break the cryptographic algorithms used in current public-key cryptography systems, including RSA and ECC. Specifically, a CRQC is a quantum computer with sufficient computational capabilities and stability to run Shor's algorithm.

The Global Risk Institute Quantum Threat Timeline Report, which our leaders' author, synthesizes global experts’ insights on the current state of quantum computing, with a focus on the threat it poses for cybersecurity.  Experts’ responses suggest that a CRQC may arise faster than many anticipate.  Experts estimate a ~17-31% chance that we will have CRQCs within a decade (up from 10-27% in 2022).  While that may sound like it’s in the future, based on other cryptographic transitions, it is less than it will take many organizations to transition to quantum-safe algorithms.

A "Harvest Now, Decrypt Later" (HNDL) attack refers to a cybersecurity threat where attackers harvest and store large amounts of encrypted data today, with the intention of decrypting it in the future when powerful quantum computers become available. Since some data has a long shelf-life – from intellectual property and trade secrets to personally identifiable information – organizations must implement quantum-safe cryptography far ahead of when CRQCs will be available.

New technologies are being used to address the quantum threat. These include Quantum Key Distribution, Post-Quantum Asymmetric Cryptography, and new Symmetric Key protocols. Each has their own advantages and challenges compared to the traditional asymmetric cryptography we have used for years, which makes each better aligned to different use cases. Most importantly, having these new tools available allows organizations to decide how best to leverage each and combine them to provide defense in depth.

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.

In many cases, PQC algorithms will help to protect data. However, a lot of data has long-term security (LTS) requirements, such as highly sensitive or confidential information and trade secrets in military, government, industry, legal, healthcare or the financial sector. PQC algorithms don’t have a long track record yet and their analysis is still ongoing. New methods for cryptanalysis and even new algorithms for quantum computers could be found that will break certain PQC algorithms. Looking into the past of classical asymmetric and PQC algorithms the likelihood for this is not negligible. Therefore, more resilient approaches should be used for data with LTS requirements.

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.

Yes.  BasejumpSIM can be deployed in a cloud instance and simulate a multi-node QKD network without using QKD hardware. Building a quantum-safe network can be expensive and has a steep learning curve.  Our BasejumpSIM product can be used by customers at the start of their quantum-safe journey to build simulations and pilots more affordably, and once a customer has learned how to successfully deploy a QKD network, they can transition to our BasejumpQDN product to migrate to a fully operational quantum network that is secure, upgradable, and economically maintainable over the long term.

No. MultimodalKES is an algorithmic approach to quantum resilience.  Multimodal keys can be combined with QKD keys to deliver a hybrid key for even more resilience in a system. Moreover, QKD can be used to fortify the secure communication between the Key Distibution Hubs.

When choosing a long-term secure key establishment solution, organizations should consider factors such as algorithm agility, interoperability, performance, scalability, and compliance with industry standards and regulations. MultimodalKES was designed to meet all of the above requirements.

Keys established through the Multimodal protocol include a symmetric secret combined with asymmetric cryptography.  LTS comes from the addition of the symmetric secret delivered out-of-band during endpoint registration.

The number of KDHs needed relies on the number of clients, your infrastructure and availability required for your organization. One KDH is the minimum, but it is highly recommended to have several KDHs for redundancy.   Both the KDH, where the initiator endpoint is registered, and the KDH, where the target endpoint is registered, need to be available to get pre-key data.  If endpoints register with more than one KDH high availability can be achieved.

The pre-key data retrieved from the KDHs can be cached and subsequently used to establish a common secret between the endpoints without the need for either of them to be connected to the KDN at that point.

MultimodalKES can be deployed both on-premise, preferably on a hardware security module (HSM), and in the cloud. Organizations can choose the deployment model that best fits their security requirements and infrastructure setup.

Deploying MultimodalKES on an HSM provides additional physical and logical protection for cryptographic keys.  HSMs are tamper-resistant devices that safeguard sensitive key material from unauthorized access and manipulation.

This depends on the protocol.  If Multimodal keys are used in TLS for example, the key is new for every TLS session establishment. In the case of IPSec, the Multimodal key could be replenished depending on a security policy.

This depends on the application. The client side of MultimodalKES is delivered as a library. The application could directly call this library to retrieve a Multimodal key. If the application already implements an interface such as ETSI QKD 014 to retrieve a shared symmetric out-of-band key, a wrapper around the library and exhibiting the required interface can be used.

Yes. Keys from BasejumpQDN or MultimodalKES are deployable at scale in many enterprise applications via existing protocols (including TLS, IPSec, MACSec and OTNSec) and infrastructures such as routers or security appliances. We also work with several leading partners, including network equipment providers, to enable streamlined integrations and upgrade paths.

Yes.  MultimodalKES end-to-end keys are based on the combination of a pre-shared-key and asymmetric algorithms (ECDH and PQC).

Additionally Multimodal keys can be combined with QKD keys from BasejumpQDN to deliver even higher levels of security.

‍

The term “last mile” commonly refers to the final leg on a network that connects an end-user’s premise to a node within the service provider’s network. In quantum-safe networks, “last mile” often refers to connecting a device to the nearest node that has a QKD device. Such devices need a different quantum-safe solution that provides long-term security, such as MultimodalKES.  

We use MultimodalKES to make a strong long-term secure (LTS) connection that can meet the quantum-safe security requirements for many use cases and applications where a direct connection to a QKD device is not available.

‍

There are advantages and challenges related to any cryptographic approach that your team should consider when defining your target quantum-safe architecture. QKD is information theoretically secure and doesn’t have the same cryptanalysis “code breaking” risk that computationally secure cryptographic techniques do – but it requires new hardware devices  and optical links, or satellites between them. MultimodalKES employs multiple techniques to be long-term secure and is able to address long-term security requirements in use cases and applications without quantum hardware. Both technologies can be combined in a target architecture to provide a defense-in-depth approach.

Moreover, MultimodalKES can provide very strong end-to-end security when QKD is not feasible due to unavailable optical links (see “last mile”).

‍

MultimodalKES can be deployed today at large scale. When single QKD links or a Quantum Key Delivery Network such as BasejumpQDN are added, QKD keys can be used to fortify the encrypted links between the elements of MultimodalKES (endpoints and Key Distribution Hubs) or to hybridize the final end-to-end keys created by MultimodalKES (in case both endpoints also have direct QKD access). In case QKD keys cannot be generated for a longer period, MultimodalKES can be used as a strong quantum-resilient fallback solution.