Quantum Readiness
Photo by Planet Volumes on Unsplash. Yes this is a quantum computer.
Quantum computing is interesting, but most people completely ignore it because it currently doesn’t exist at a usable and effect scale, and they simply have other things that seem more involved and immediate. But there are some elements that the security community needs to be aware of, and there are some things that can be done proactively right now to address future concerns - namely Post-Quantum Cryptography.
What is the Post-Quantum Cryptography Threat?
Post-Quantum Cryptography (PQC) references new cryptographic algorithms that are resistant to quantum computers running specific algorithms that can break certain existing older cryptographic algorithms. Normally these older cryptographic algorithms were considered mathematically complex enough that conventional computers would have to run for years (if not decades or even centuries) to crack the encryption, but quantum computers can run specific algorithms that allow them to break some of these older encryption methods in a much shorter amount of time. The computer that can do this level of encryption cracking is referred to as a cryptanalytically-relevant quantum computer, or CRQC. Currently there are no existing CRQCs but that is expected to change over the next several years.
The exact threat is this - by using Shor’s Algorithm and a large and stable enough CRQC, asymmetric algorithms (aka public key algorithms) such as Rivest-Shamir-Adleman (RSA), Elliptic Curve Diffie-Hellman (ECDH), and Elliptic Curve Digital Signature Algorithm (ECDSA) can be broken. The most common area where these algorithms are used is in TLS - the heart of encrypted web traffic. Public key cryptography is also used in other communication channels as well, such as SSH.
Are symmetric algorithms safe? Yes, if the strength is large enough. SHA-256 is considered “quantum resistant” whereas SHA-128 is not. Using Grover’s Algorithm, a CRQC could cut the strength in half more or less, so a SHA-128 becomes the equivalent of SHA-64 which is considered breakable. The same thing applies to AES where the minimum recommended strength is AES256 for quantum resistance.
What is Q-Day?
Q-Day is basically the day that CRQC becomes a reality. Advances in quantum computing are happening constantly where the systems are slowly becoming larger and less error-prone, which shortens the time when Q-Day or “the Q event” or whatever term you like to use will actually occur.
The existing threat right now is the principle of “harvest now, decrypt later”. The concern is that encrypted material now can be gathered by an adversary, and when Q-Day happens then the decryption can occur. This means that if you have secrets you needed to keep secret for around 5 to 10 years, you should be using quantum resistant algorithms now.
The U.S. Government was of course concerned, hence the Post-Quantum Cryptography project from NIST, with a lot of input (and all of the testing) from the NSA. Development of new algorithms was needed, and the project came up with some solutions.
What is “safe” to use?
Three standards emerged in 2024 - FIPS 203 with the new ML-KEM, FIPS 204 with the new ML-DSA, and FIPS 205 with the new SLH-DSA. These algorithms have been tested by the NSA as well as fully peer-reviewed by the wider cryptography community and various research labs at large companies and universities. By using these algorithms for asymmetric encryption along with existing safe symmetric algorithms, one can be safe from the coming Q-Day and has a level of mitigation from the harvest now, decrypt later scenario.
Slowly the various cryptographic libraries (for example OpenSSL) are adding these new algorithms. Of course this means updating those libraries on the systems you want to help protect, and then configure those algorithms to actually be used. Granted this does mean that not only both ends of the communication for such things as TLS need to be not only updated but configured properly. Many stable operating systems such as Linux distributions like Ubuntu and Red Hat are slow to update these types of libraries so you have to make the decision whether you want to manually upgrade the libraries or simply wait for the next stable versions to include the updated libraries.
Checking Live Systems
On my home systems (the servers run Ubuntu 24.04 LTS) the main services I wanted to check were HTTPS and SSH. So I wrote a utility in Python that does exactly that, and I made sure that I could run it locally or remotely. The basic code was written by myself, and I used a combination of GitLab CI testing and building adjustments along with Anthropic Claude to clean up the code and make it pretty. Claude recommended a number of features but I certainly didn’t use all of them, and of course I did my usual of relaunching a new chat to get Claude to look at “potentially buggy code” to find problems including security flaws I might have missed.
The code can be found here, feel free to use it. I had a lot of fun writing this code as I used Claude Code during the latter parts of development, and I experimented with an interesting claude.md file which I will cover in another blog post. Regardless, enjoy the code and have fun pointing it at various systems you manage.
