16 Sep 2022 5 min read

Frequently asked questions (FAQs)

Why QuSecure?

This FAQ list explores the most common questions we hear when working with customers to evaluate their quantum exposure and QuSecure’s solutions.


1. AES is immune from quantum attacks; why do I need you?

Although AES-256 (NIST Level 1 security) is secure, asymmetric algorithms are used to establish the symmetric key they use. RSA and ECC are no longer secure, so the NIST post-quantum algorithms must be used.

To get the best performance from the NIST post-quantum algorithms, our solution must be used in place of TLS. The challenge with AES is not in the algorithm. It is in the transmission of the key.

It will be possible for quantum computers to intercept the key transmission and decrypt the data. In addition, we are also expanding on AES and the universal hashing algorithm it uses to enable NIST Level 3 and Level 5 security.


2. I have heard that quantum computers are many years away; why should I care about this now? 

While quantum computing is still an emerging field, leading experts in the industry believe that a CRQC (Cryptographically Relevant Quantum Computer), a quantum computer that can break current cryptography, will be available within the next 3-5 years.

Additionally, nation-state attackers are stealing encrypted data that will be retroactively decrypted once a CRQC is available. This is a well-documented attack campaign strategy known as ‘Steal Now Decrypt Later.’ It is estimated that nation-state attackers have stolen up to 25% of global encrypted data.

China has also dedicated a $100B budget to developing a CRQC with over 1,100 quantum engineers working on the project.

Enterprises need to take measures now to comply with future NIST post-quantum standards and assume fiduciary responsibility for their data security.


3. Why is a quantum key better than a pseudo-random key?

Entropy acts as a measure of how difficult a symmetric key is to break. Quantum Random Number Generation (QRNG) produces symmetric keys with maximum entropy.

While a pseudo-random key can have relative entropy, the time it takes to generate such a pseudo-random key is many orders of magnitude greater than the time it takes to create a quantum key.


4. Why should I use Post-Quantum Cryptography (PQC) vs. Quantum Key Distribution (QKD)?

QKD implementations lack maturity and face significant challenges regarding long-distance entanglement, one-to-many, and many-to-many configurations.

Given the imminent rise of quantum computers, a different (more feasible) approach is needed to secure the sockets layer in time.

QKD is also expensive and focused on backhaul fiber connections. NSA recently pushed guidelines for quantum security and reiterated that QKD would not be viable for a general deployment of quantum security.


5. What is wrong with PKI?

In addition to the typical difficulties in PKI implementations and the vulnerabilities created by implementation mistakes, the PKI fundamental design flaws become apparent and significant. Due to reliance on the Certification Authority (CA) within the PKI schema, and since several Certification Authorities have been breached over the past several years, PKI is no longer seen as a secure method of secure communications. Moreover, reliance on third-party CA’s reduces the speed with which the communications process occurs. Therefore, QSL offers a more secure and reliable infrastructure to the communication process, which also features improved performance.


6. What is quantum about QuSecure’s solution?

The only actual quantum element of our solution is our quantum random number generator within our Orchestrator. These orchestrators can be deployed behind your firewall as an appliance or accessed from our private cloud. We have a third hybrid option that lets the device communicate with our private cloud orchestrator for high availability.


7. Can we implement just portions of your platform’s capability that we have gaps in? Will it still work?

A client can implement portions of our solution. For example, we currently offer management of data-at-rest (encryption/decryption) and file transfer. In the future, we will provide Hypertext transfer and remote shell. A client might say they only want data-at-rest and hypertext transfer, and we could do that for them. However, we will ensure that the clients know what they will miss.


8. Why can’t I use the NIST algorithms? They are free.

Anyone can use the NIST algorithms as they will be open-source/open standard. However, these algorithms are not simply plug-and-play; surrounding security processes and systems can still be vulnerable.

A holistic Post Quantum cybersecurity solution is best if you want the best performance from the algorithms. This is one of the reasons why QuSecure built our Quantum Secure Layer (QSL) instead of using TLS.


9. Why are you faster than TLS? 

QSL has only one public/private key pair belonging to our server (clients never need to call expensive key generation algorithms). QSL uses a Key Encapsulation Mechanism (KEM) private key as the root of trust (enabled by the fact that KEMs are INDCCA2 secure), while TLS uses a Digital Signature (DS) private key.

QSL uses KEM at the login step, while TLS uses DS at the certificate signing request step. (KEM operation ~ 10 microseconds, and DS operation ~ 100 microseconds). QSL uses only authenticated symmetric encryption during the two-round trips. In contrast, TLS uses DS, KEM, and authenticated symmetric encryption (Authenticated symmetric encryption operation ~ 1 microsecond, KEM operation ~ 10 microseconds, and DS operation ~ 100 microseconds).

In TLS, the two round trips are between the same two devices (~ 100 milliseconds). At the same time, QSL has an intermediate server (our server) that handles the first round-trip (~ 50 milliseconds) so that the second machine (considered a server in TLS but often referred to as a second client QSL) only handles the second round-trip (~ 50 milliseconds).

As a result, each client accepted that using QSL would consume ~ 50 milliseconds on the socket and ~ 1 microsecond of processor time. In comparison, each client accepted that using TLS would consume ~ 100 milliseconds on the socket and ~ 100 microseconds of processor time.


Are you ready? Contact us today.

Find out more