Quantum Resistant Cryptography: Why Should You Be Concerned Now?

By | | Categories: quantum resistance

Quantum computing is a relatively new endeavor in the field of computing. Research into it began back in the early 1980s, and it has been progressively gaining momentum in recent years.

One of the major concerns around quantum computing is its ability to break existing (asymmetric) public key cryptographic systems using Shor's algorithm., which enables computers to find prime factors quickly. This is something that normal computers have not been able to do, and is an assumption that underpins algorithms like RSA, Diffie Hellman, and ECC.

While there is plenty of research and development being invested into quantum computing, by my estimate we are realistically at least 30 years away from seeing quantum computers in use for breaking cryptography.

So why are so many concerned about it right now? And why should you be concerned about what that future holds?

Harvesting data today to decrypt tomorrow

When it comes to quantum computing, one of the biggest concerns amongst organizations like the Department of Defense, financial institutions and healthcare providers is the fact that information harvested and stored today could potentially be decrypted in the future.

If you are transmitting encrypted information today with an algorithm that could be broken by a quantum computer, it would be possible for malicious actors to intercept that information, store it in its encrypted form, and save it for a future date.

Once a quantum computer is built that has the speed and processing power capable of breaking that algorithm, it can be used to decrypt and access any information that was previously stored.

So, essentially, you should be concerned about using quantum-resistant cryptography if you have sensitive information that would still be a problem if it was discovered and released in 20 to 30 years.

This is why the government, specifically the Department of Defense, is concerned about employing quantum-resistant cryptography today. Much of the classified information that needs to be protected today will still be classified in 30 years, and could potentially still do a lot of harm if released 30 years down the line.

Another prime example is related to healthcare. Intercepting encrypted medical records today could mean the wide release of personal health information protected by HIPAA in the future.

While 30 years may feel like it is far away, the release of nearly all the information you are working to protect today is a big concern, even when the threat is that far into the future.

Using quantum-resistant cryptography

The good news is that it is absolutely possible to avoid the risks I mentioned above with today’s technology. Quantum-resistant cryptography, which is available now, can protect data from the threats of the future. 

Internet Protocol Security (IPSec) encryption has been the standard used to secure data any time it moves between two or more computers and/or networks over the internet. It includes protocols for establishing mutual authentication between agents at the beginning of a session, and negotiation of cryptographic keys to use during the session.

Internet Key Exchange (IKE) is the protocol used to set up a security association in the IPSec protocol suite, and it comes in two flavors, IKEv1 and IKEv2.

IKEv2 is based on the Diffie-Hellman (DH) exchange, created to allow two parties to jointly establish a shared secret cryptographic key over an insecure public channel. Today, all of the authentication methods that make IKEv2 possible can be broken by a quantum computer.

Common methods for establishing authentication over IKEv2 include RSA and Elliptic Curve Digital Signature Algorithms (ECDSA).

By contrast, IKEv1 does not rely just on a DH exchange to establish authentication. Initially, IKEv1 was meant for more general-purpose key exchange, and thus had many extraneous features that were removed with the switch to IKEv2.

Using IKEv1 with a pre-shared secret key (PSK) for authentication is considered "quantum safe".

In this case, each endpoint for communication knows the identity of the endpoint at the other end and has pre-shared its secret key. This approach is usually found in gateway-to-gateway VPN deployments.

Secure communication methods using IKEv1 combined with pre-shared keys and using the AES-256 (symmetric) encryption algorithm are the best bet for quantum-safe applications. Although other quantum safe algorithms exist, they have not gone through the rigor and years of proven reliability that IKEv1 and AES have.

Additional requirements

There are a few additional requirements that must be met to make the use of IKEv1 with pre-shared keys work from a tactical perspective.

First, a pre-shared key of at least 22 characters should be used when employing IKEv1 with pre-shared keys.

One of the struggles with establishing a quantum-safe key is the size of the keys needed to establish authentication. When sending messages that carry the key establishment information using IKE, those messages will have to be fragmented if they are too long.

Many fragmented IP packets will be filtered out by firewalls, proxies and network address translators at the receiver, meaning that the recipient will not get the key establishment information.

Thus solutions using IKEv1 with a pre-shared secret key will need to support the fragmentation of key shares to support those quantum-safe algorithms which require large keys.

Final thoughts

While the threats of quantum computing may not be immediate, the effects of ignoring it (even now) could be significant. Because there are clear, and relatively simple, steps you can take today to avoid the problem, why wait?

All you need to do is ensure you have communication methods in place to transmit information using cryptography that is quantum-resistant, particularly if you are transmitting that information across the open internet or publicly accessible networks where it could be easily intercepted and saved.

GoSilent is quantum resistant click to learn more


Subscribe me to: