When someone says “quantum computer,” it still sounds like a problem from the future. Something that might eventually arrive, break RSA, and give us a reason to deal with it.
That is not how cryptographic migration works. The quantum problem does not start on the day someone builds a sufficiently powerful machine. It starts when data needs to stay secret for longer than the transition to new cryptography will take.
No quantum computer can practically break RSA or elliptic-curve cryptography today. I do not want to turn this into a countdown to disaster. It still makes sense to start now.
Data can outlive the system protecting it
Plenty of data loses its value quickly. A one-time code or a short-lived operational message may not be sensitive ten years from now.
Other data will remain valuable. Medical records, product know-how, long-term contracts, financial information, identity data, government communication, or information from products with long life cycles can remain valuable far into the future.
This is where harvest now, decrypt later comes in. An attacker does not need to break today’s encryption today. Capturing the traffic, storing it, and waiting for better tools may be enough. The joint CISA, NSA, and NIST quantum-readiness guidance connects PQC preparation not only to future quantum capability, but also to data lifetime, inventory work, and vendor engagement.
That is the important shift for me. The question is not only when will a quantum computer be strong enough? It is also how long must my data remain protected? and how long will it take me to change the systems protecting it?
The standards are no longer theoretical
There is another, much less dramatic reason to work on this now: we have something concrete to work with.
In August 2024, NIST finalized its first three post-quantum cryptography standards:
- FIPS 203 / ML-KEM for establishing shared secrets,
- FIPS 204 / ML-DSA for digital signatures,
- FIPS 205 / SLH-DSA for hash-based digital signatures.
NIST now encourages organizations to begin the transition, including inventorying systems that use encryption and talking to vendors about the change.
That does not mean replacing RSA with ML-KEM everywhere tomorrow. It means PQC is no longer only an academic algorithm competition. The standards exist, and the less exciting work begins: finding where current cryptography is used and understanding what can actually be changed.
Cryptography is everywhere, but it is rarely visible
When I got deeper into this topic, the most interesting part was not the quantum computer itself. It was the mess around today’s cryptography.
It sits in TLS certificates, application and firmware signing, JWT flows, VPNs, libraries, HSMs, mobile apps, devices, cloud services, and vendor products. Some of it is directly in code. Some is hidden in configuration. Some has no clear internal owner because a vendor set it up years ago and it has worked ever since.
While everything works, there is little reason to notice it. But an algorithm migration is not one package update. It can affect key and signature sizes, certificates, protocols, hardware, performance, compatibility, and the entire chain of trust.
The biggest problem may not be the old algorithm. It may be the fact that nobody knows exactly where it is or who can change it.
That is why I am building PQC Radar
This is where PQC Radar came from. Its purpose is not to put a “quantum safe” badge on a company. That would be a very bold claim today.
I want it to provide a practical first step: inspect an approved scope, find signals of classical public-key cryptography, build an initial cryptographic inventory, and turn it into priorities that make sense both technically and commercially.
PQC Radar can look for things such as:
- RSA, ECDSA, ECDH, Ed25519, and other classical algorithms in repositories,
- certificates, signature algorithms, keys, and expiry dates,
- explicitly authorized public TLS endpoints,
- signing, PKI, and other cryptographic dependencies,
- evidence for a CBOM-style inventory and later manual validation.
It is discovery, not magic. A heuristic scan cannot understand the whole business context, and a finding in code does not prove that the path runs in production. Automated collection therefore needs validation by the people who actually own the product.
What I would ask first
If I were responsible for a long-lived product today, I would not start with “how quickly can we deploy ML-KEM?” I would start with much more boring questions:
- Which data must stay confidential for five, ten, or twenty years?
- Where do we use RSA, ECC, Diffie-Hellman, or digital signatures?
- Which dependencies do we control, and which belong to a vendor?
- How do we sign software, firmware, and updates?
- Who owns the migration if a change is required?
These are not questions for a cryptographer alone. They cross architecture, security, engineering, procurement, risk, and company leadership.
PQC matters not because the internet will stop working tomorrow. It matters because large cryptographic changes take years, and the worst possible starting point is “we do not know what we have.”
In part two, I will get more practical: how to build the first cryptographic inventory and turn it into a migration roadmap without starting a giant audit of everything.
답글 남기기