From TFA: "The policy reflects growing concern about Harvest Now, Decrypt Later (HNDL) attacks, in which adversaries intercept and store encrypted communications today with the intention of decrypting them once a cryptographically relevant quantum computer (CRQC) becomes available."
Once it gets to be "later" where the harvest data is able to be decrypted, I guess will have decent enough LLMs to summarize all of that data? Otherwise, there's going to be such a huge back log to make it not too useful
I was at ANSSI headquarters last year doing a technical presentation and several of their questions were about Post-Quantum Cryptography, "Q day" (when a practical Quantum Computer is expected) and other related things. They keep a close eye on this stuff and it's to their credit. Similarly the BSI in Germany have been promoting Post-Quantum security for some time now.
I work at AWS, where we have been deploying Post-Quantum Cryptography for quite some time and have experts. We're making easier than ever, but the sudden changes in deadlines do make me wonder how many companies are going to have to spend more time than they'd planned on migrations and settings. The "context switch" of working on PQ can be quite expensive. Most tech people have no idea what ML-KEM, ML-DSA, or HQC are, or how to not worry about SHA, HMAC, or AES. It's going to be a ride!
I'm very curious how much people will look back on this frenzy of PQC migration panic by 2050 when, my bet, there still won't be any remotely viable QCs. The decade plus of even slower TLS negotiation that this will bring in the name of "security", after so much time spent previously on improving encrypted connection latency, will seem quite comical, at least.
It really depends on the market you are targeting and your threat model. If your threat model allows future decryption of the data by a passive listener, then you don't need to rush for PQC. If you are worried about your communications being archived for future decryption, then you need to deploy PQC now even if QCs aren't developed for decades (or ever).
The assumption that you care about this is baked into ANSSI certifications, otherwise you would usually not bother certifying your product. They warned in 2022 that they would do this (See Phase 2: https://messervices.cyber.gouv.fr/guides/en-anssi-views-post...) and will allow PQC-only algorithm no earlier than 2030.
You prepare for the 9.0 earthquake that can happen once in 500 years because it is a 9.0 earthquake and if you haven't prepared your society is dead, not because you think it will most likely happen in your lifetime.
The countries that do prepare for catastrophic megaquakes do so despite the fact that the incidence frequency is quite low, because the consequence magnitude is so great.
Even regions with few quakes may have a history of large quakes. The New Madrid region (southern Illinois, southeastern Missouri, southwestern Kentucky, northwestern Tennessee, northeastern Arkansas) doesn't experience especially frequent temblors, but when they do occur, they're doozies:
Not entirely true. Australian emergency services routinely prep for earthquake despite having only one or two decent shakes causing mass damage in recorded post colonisation history.
That prep doesn't extend to building standards for higher magnitude quakes.
Appropriate prep is still important for a possible credible threat, even if it is likely to be a rare issue, and the magnitude of that prep differs by personal posture and exposure.
I'm logging into websites using unique passwords with 44 bits of entropy, which they feed into a hash algorithm that takes 200ms to hash each attempt, then entering a TOTP code or touching my Yubikey, and they check against my geoip history and fingerprint my browser and they want me to complete a captcha and they e-mail/SMS a one-time code to me and they send me an e-mail telling me there's a new login to my account.
The security industry loves to use belt and belt and braces and braces and braces. If they add an extra belt or two, I doubt anyone will remark on it at all.
The two key issues PQC try to address are key exchange and digital signature, which happen during TLS handshake, the mechanism you described happen after TLS is established; so if a quantum computer breaks TLS, then it effectively reduced HTTPS to HTTP
It's only reasonable to call past decisions comical when you can look back and say there was certainly no reason to have ever been concerned at the time with the information and certainty of the time, not whether or not it actually turned out that way in the future and you get to judge the response with the outcome already in hand.
I wouldn't categorize it as a panic. Standards and security organizations are recommending moving to PQC based on projections of capability. CloudFlare and Google recently moved their timeline forward for PQC migration based on new data[1][2].
I don't think the TLS negotiation will become meaningfully slower, as there are multiple threads being pulled on for how to make post quantum happen here with minimal regression, instead it will likely become meaningfully more complex and only slightly slower, continuing a trend that has been ratcheting for quite some time now. ECH and modern certificate revocation checking schemes are also contributing to this.
The increase in complexity is a huge problem. It is arguably justifiable but simultaneously concerning. It's already quite hard to make a correct TLS implementation as it is.
(Personally though, I still like post quantum encryption. It's a nice hedge in case ECC and/or RSA do fall any time soon, whether by quantum computer or simply math.)
Y2K devs had it easy, they knew the bug would arrive and when.
The problem with PQC is not that nobody knows when a CRQC (cryptographically relevant quantum computer) will appear, but that by the time it appears, you are already ~10 years too late for migrating (5 years of migration time and 5 years of your adversary silently storing all your classical crypto messages to decrypt them at a later time, the "harvest now decrypt later" attack).
Of course the HNDL attack is only relevant for the most critical pieces of infrastructures, 99% of companies are not a real target for that, especially given the storage cost of such an attack.
There is also the "trust now, forge later" attack, in which a CRQC could break a chain of trust (i.e. digital signatures), and that attack does not need any storage besides the logs of past messages. If you want to guarantee authenticity and unforgeability of your logs for, say, 20 years, you better hope that no CRQC appears by 2050 at least. Once again, it only concerns maybe 1% of companies.
But hey, these 1% companies are exactly the ones that are needing specialised crypto equipment so the move from ANSSI tracks.
I personally do not believe a CRQC will appear before 2050 either. I am willing to bet some money on it, despite researchers in quantum computers being quite confident it will appear in the next 15 years, but I am not willing to bet the entirety of Internet security on it.
Ironically, given that the primary use case for developing quantum computers is breaking classical encryption, switching en-masse to post-quantum schemes may very well ensure that developing a working quantum computer may never be economically viable to develop.
Certainly, we can imagine other use cases for quantum computers. But just because something could be useful doesn't mean it will be developed; the cost still needs to be surmountable.
Logistics companies are using hybrid QC now from D-Wave Systems. Quantum computing is currently in use in the real world. There's already physics simulations running on QC hardware beyond the capacities of classical computing, QuEra's Gemini is already doing materials science work now. It's very expensive, giant logistics companies and other industries with lots of capital and the need to do the special kinds of simulations these things are good at will be renting time on these things from specialized vendors who can run this kind of intensive hardware, something like time sharing on a supercomputer. Quantum-as-a-Service (QaaS) via platforms like Amazon Braket, Azure Quantum, or IBM Quantum Platform is already a thing. Big Pharma will be renting this stuff, Google currently plans to have QC for Pharma applications running c. 2028-2030. Lots of folks dealing with materials sciences and so on will be on projects where this will be affordable since not everything needs a massive CRQC to be useful.
That wasn't just a list of things they could besides breaking crypto. It was the list of the main reasons people are investing in trying to build them.
As you noted the problems they pose for cryptography can be addressed with PQC. Military/Defense/National Security invests in them for the cryptographic applications (and probably also for the logistics applications), but they are only about 1/3 of the investment.
The rest is for the doing better physics simulations and for logistics and financial applications. The physics simulations will be huge and drug development and materials science.
The history of diligence in properly utilising and applying security measures strongly suggests that QC will in fact provide positive utility even if viable PQC countermeasures are developed and deployed.
> I'm very curious how much people will look back on this frenzy of PQC migration panic by 2050 when, my bet, there still won't be any remotely viable QCs.
The funny thing is there's, for the foreseeable future (decades), no viable QCs at all expect breaking non-QC cryptography.
And should breaking non-QC cryptography become even remotely possible, the effect is going to be that everything is going to shift, like SSH, to an hybrid solution with two algos: good old non-QC resistant algo and new fancy QC-resistant algo.
So basically QC will have achieved jack shit besides moving everybody to use two algos instead of one.
In 2060 you'll have one device able to use quantum computing to break some messages from 2030, incriminating old senile or long dead politicians, that nobody will give any shit about.
That's the weirdest thing about this whole thing: the only viable QC we hear about is "breaking cryptography" but as soon as that becomes a possibility, we'll all be moving (just like TFA and OpenSSH are showing btw) to QC-resistant algos.
Making QC non-viable.
So... Besides cracking old obsolete message, what the heck can QC be used for?
I mean: what good are those machines going to bring the world, besides cracking old messages nobody cares about and besides making every switch to QC-resistant schemes (like hybrid old+new algos)?
> by 2050 when, my bet, there still won't be any remotely viable QCs
I hate to be that guy, but I'm 52 now and I've been hearing about how Quantum Computing is going to revolutionise everything in the next two years, since I was in primary school and ZX81s were state-of-the-art.
At least a couple of manufacturers offered a practical and afforable(-ish) transputer-based system in the 80s that you could have actually gone out and bought.
Agreed. This looks from the outside like someone read a report, got unnecessarily spooked, and now the rest of the herd is following along.
But it's also very possible that hypothetical report was genuinely concerning. We just haven't seen it or anything like it.
However I'm pretty firmly in the "quantum computing won't be doing anything useful any time soon, if ever" camp, so that definitely colors my opinions. I don't have any particular recent expertise to support that, but I did used to share an office with some serious QC people and go to their talks so... make of my words what you will.
Would anyone downvoting care to explain? I'm genuinely interested in seeing anything that suggests there's either some secret breakthrough (completely plausible, but there's no evidence that I've seen hint of) making quantum computers actually useful, or an argument that they'll be usable by (say) 2050?
Because right now my attitudes are trained by things like this https://algassert.com/post/2500 that explain just why 15 was factored in that famous run of Shor's algorithm and not, say, 21; and why 21 hasn't been factored yet and isn't likely to be any time soon....
I work as a security architect in a major European company. We're currently demanding a full cryptographic inventory of every new product purchased or service built in-house and will start demanding PQC in 2028.
Not because we expect a workable quantum computer by 2030 (current estimates are around 2035-2040), but because stuff survives for decades in large enterprises (especially if it touches hardware in any way. Think OT, think controllers for all kinds of machines).
Now that PQC is standardized, there's no gain not to demand it (it's basically a demand to use a current openSSL/libreSSL/$library), but not demanding it now will cause a major headache once/if quantum computers work.
TLS connection speed matter only for a very tiny niche of applications; those will choose according to their needs. For the general case, it just doesn't matter.
If your threat model includes store-now-decrypt-later, you should have been demanding PQC for years.
Man, the CBOM is such a pain. There is no standardised format yet (let alone efficient tools for crypto discovery), nobody knew what it was one year ago but now every client is asking ours anyway.
Tell me about it! We've got slightly under 10'000 distinct software assets we are trying to catalogue. There are now a handful of vendors claiming to be able to scan for crypto, but they all suck.
I'm not even there for my employer. I have compiled a list of ~20 different inventory/CBOM solutions and I cannot even fathom how to move to the next step other than picking a few vendors at random and ask them for a demo, but the public info I found was not convincing.
While I can assume these tools do a decent job at crypto asset discovery (a `grep -r "-----BEGIN RSA PRIVATE KEY-----"` is not the hardest product to design), I have no idea what to do for code scanning. CBOMkit and friends do not scan C code, which we actually need.
There has been a lot of new stuff over the last few years.
For instance, breaking RSA or ECDSA is requiring much fewer logical qubits than previously thought, and thus fewer physical qubits as well. Progress in error codes, quantum processing etc. made it that in 2019, it was estimated we needed ~20 million noisy qubits to factor RSA 2048. In 2025, we know we need fewer than 1 million. [0]. Some other papers even claim the need of 1000 physical qubits but they rely on a very exotic architecture so I would not consider them feasible.
Progress on the hardware is also continuing, see [1]. Researchers managed to have functional-ish error correction for the first time last year, and experts in the topic are confident that a cryptographically relevant computer will appear in around 15 years.
I personally am less optimistic than the experts (admittedly I am not an expert either), but there is enough activity to get worried for critical infrastructure.
Regarding the factoring issue, as you point out factoring 15 and factoring 21 are two very different tasks. The first one can be used to show that your quantum computer is indeed doing quantum computation; the second will prove that you have a functional error correcting code. If you can factor 21, it is probably only a matter of months/maybe a few years until you factor RSA 2048. As Scott Aaronson said [3], "Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”"
PQC: Post-Quantum Cryptography.
The concern is systems which won't be resistant against quantum cryptographic attacks.
The US's NIST has an explainer page, "Post-Quantum Cryptography PQC":
<https://csrc.nist.gov/projects/post-quantum-cryptography>.
Related: https://news.ycombinator.com/item?id=48992806 (Are 128-bit symmetric keys really secure against quantum computers?)
From TFA: "The policy reflects growing concern about Harvest Now, Decrypt Later (HNDL) attacks, in which adversaries intercept and store encrypted communications today with the intention of decrypting them once a cryptographically relevant quantum computer (CRQC) becomes available."
Once it gets to be "later" where the harvest data is able to be decrypted, I guess will have decent enough LLMs to summarize all of that data? Otherwise, there's going to be such a huge back log to make it not too useful
I was at ANSSI headquarters last year doing a technical presentation and several of their questions were about Post-Quantum Cryptography, "Q day" (when a practical Quantum Computer is expected) and other related things. They keep a close eye on this stuff and it's to their credit. Similarly the BSI in Germany have been promoting Post-Quantum security for some time now.
I work at AWS, where we have been deploying Post-Quantum Cryptography for quite some time and have experts. We're making easier than ever, but the sudden changes in deadlines do make me wonder how many companies are going to have to spend more time than they'd planned on migrations and settings. The "context switch" of working on PQ can be quite expensive. Most tech people have no idea what ML-KEM, ML-DSA, or HQC are, or how to not worry about SHA, HMAC, or AES. It's going to be a ride!
I'm very curious how much people will look back on this frenzy of PQC migration panic by 2050 when, my bet, there still won't be any remotely viable QCs. The decade plus of even slower TLS negotiation that this will bring in the name of "security", after so much time spent previously on improving encrypted connection latency, will seem quite comical, at least.
It really depends on the market you are targeting and your threat model. If your threat model allows future decryption of the data by a passive listener, then you don't need to rush for PQC. If you are worried about your communications being archived for future decryption, then you need to deploy PQC now even if QCs aren't developed for decades (or ever).
The assumption that you care about this is baked into ANSSI certifications, otherwise you would usually not bother certifying your product. They warned in 2022 that they would do this (See Phase 2: https://messervices.cyber.gouv.fr/guides/en-anssi-views-post...) and will allow PQC-only algorithm no earlier than 2030.
You prepare for the 9.0 earthquake that can happen once in 500 years because it is a 9.0 earthquake and if you haven't prepared your society is dead, not because you think it will most likely happen in your lifetime.
Most countries don't prepare for earthquakes. Only countries that get earthquakes do.
YAGNI - https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
The countries that do prepare for catastrophic megaquakes do so despite the fact that the incidence frequency is quite low, because the consequence magnitude is so great.
Even regions with few quakes may have a history of large quakes. The New Madrid region (southern Illinois, southeastern Missouri, southwestern Kentucky, northwestern Tennessee, northeastern Arkansas) doesn't experience especially frequent temblors, but when they do occur, they're doozies:
<https://en.wikipedia.org/wiki/1811%E2%80%931812_New_Madrid_e...>
The potential risks of PQC are large enough that preemptive countermeasures seem prudent.
Not entirely true. Australian emergency services routinely prep for earthquake despite having only one or two decent shakes causing mass damage in recorded post colonisation history.
That prep doesn't extend to building standards for higher magnitude quakes.
Appropriate prep is still important for a possible credible threat, even if it is likely to be a rare issue, and the magnitude of that prep differs by personal posture and exposure.
I'm logging into websites using unique passwords with 44 bits of entropy, which they feed into a hash algorithm that takes 200ms to hash each attempt, then entering a TOTP code or touching my Yubikey, and they check against my geoip history and fingerprint my browser and they want me to complete a captcha and they e-mail/SMS a one-time code to me and they send me an e-mail telling me there's a new login to my account.
The security industry loves to use belt and belt and braces and braces and braces. If they add an extra belt or two, I doubt anyone will remark on it at all.
The two key issues PQC try to address are key exchange and digital signature, which happen during TLS handshake, the mechanism you described happen after TLS is established; so if a quantum computer breaks TLS, then it effectively reduced HTTPS to HTTP
The amount of time I spend per day waiting for my web browser to do about 10 redirects through Okta and touch a Yubikey is substantial.
It's only reasonable to call past decisions comical when you can look back and say there was certainly no reason to have ever been concerned at the time with the information and certainty of the time, not whether or not it actually turned out that way in the future and you get to judge the response with the outcome already in hand.
I wouldn't categorize it as a panic. Standards and security organizations are recommending moving to PQC based on projections of capability. CloudFlare and Google recently moved their timeline forward for PQC migration based on new data[1][2].
1. https://blog.cloudflare.com/post-quantum-roadmap/ 2. https://blog.google/innovation-and-ai/technology/safety-secu...
I don't think the TLS negotiation will become meaningfully slower, as there are multiple threads being pulled on for how to make post quantum happen here with minimal regression, instead it will likely become meaningfully more complex and only slightly slower, continuing a trend that has been ratcheting for quite some time now. ECH and modern certificate revocation checking schemes are also contributing to this.
The increase in complexity is a huge problem. It is arguably justifiable but simultaneously concerning. It's already quite hard to make a correct TLS implementation as it is.
(Personally though, I still like post quantum encryption. It's a nice hedge in case ECC and/or RSA do fall any time soon, whether by quantum computer or simply math.)
Most fire hydrants are never used either, but we don't consider them wasted.
In your opinion, what chance of QC would warrant PQC migration? Would you be ok with a 20% chance of everyone being caught unprepared? 30%? 50%?
Keep in mind the impact is "hackers can take control of almost all online infrastructure and forge almost any document".
Y2K devs had it easy, they knew the bug would arrive and when.
The problem with PQC is not that nobody knows when a CRQC (cryptographically relevant quantum computer) will appear, but that by the time it appears, you are already ~10 years too late for migrating (5 years of migration time and 5 years of your adversary silently storing all your classical crypto messages to decrypt them at a later time, the "harvest now decrypt later" attack).
Of course the HNDL attack is only relevant for the most critical pieces of infrastructures, 99% of companies are not a real target for that, especially given the storage cost of such an attack.
There is also the "trust now, forge later" attack, in which a CRQC could break a chain of trust (i.e. digital signatures), and that attack does not need any storage besides the logs of past messages. If you want to guarantee authenticity and unforgeability of your logs for, say, 20 years, you better hope that no CRQC appears by 2050 at least. Once again, it only concerns maybe 1% of companies.
But hey, these 1% companies are exactly the ones that are needing specialised crypto equipment so the move from ANSSI tracks.
I personally do not believe a CRQC will appear before 2050 either. I am willing to bet some money on it, despite researchers in quantum computers being quite confident it will appear in the next 15 years, but I am not willing to bet the entirety of Internet security on it.
Ironically, given that the primary use case for developing quantum computers is breaking classical encryption, switching en-masse to post-quantum schemes may very well ensure that developing a working quantum computer may never be economically viable to develop.
A large part of the investments in developing quantum computing are for drug discovery, materials science, and logistics.
Certainly, we can imagine other use cases for quantum computers. But just because something could be useful doesn't mean it will be developed; the cost still needs to be surmountable.
Logistics companies are using hybrid QC now from D-Wave Systems. Quantum computing is currently in use in the real world. There's already physics simulations running on QC hardware beyond the capacities of classical computing, QuEra's Gemini is already doing materials science work now. It's very expensive, giant logistics companies and other industries with lots of capital and the need to do the special kinds of simulations these things are good at will be renting time on these things from specialized vendors who can run this kind of intensive hardware, something like time sharing on a supercomputer. Quantum-as-a-Service (QaaS) via platforms like Amazon Braket, Azure Quantum, or IBM Quantum Platform is already a thing. Big Pharma will be renting this stuff, Google currently plans to have QC for Pharma applications running c. 2028-2030. Lots of folks dealing with materials sciences and so on will be on projects where this will be affordable since not everything needs a massive CRQC to be useful.
That wasn't just a list of things they could besides breaking crypto. It was the list of the main reasons people are investing in trying to build them.
As you noted the problems they pose for cryptography can be addressed with PQC. Military/Defense/National Security invests in them for the cryptographic applications (and probably also for the logistics applications), but they are only about 1/3 of the investment.
The rest is for the doing better physics simulations and for logistics and financial applications. The physics simulations will be huge and drug development and materials science.
The history of diligence in properly utilising and applying security measures strongly suggests that QC will in fact provide positive utility even if viable PQC countermeasures are developed and deployed.
From yesterday's posts: <https://news.ycombinator.com/item?id=48983610> (my comment on the Romanian land registry hacking thread).
I'm afraid I don't see how the linked comment demonstrates the positive utility of QC.
> I'm very curious how much people will look back on this frenzy of PQC migration panic by 2050 when, my bet, there still won't be any remotely viable QCs.
The funny thing is there's, for the foreseeable future (decades), no viable QCs at all expect breaking non-QC cryptography.
And should breaking non-QC cryptography become even remotely possible, the effect is going to be that everything is going to shift, like SSH, to an hybrid solution with two algos: good old non-QC resistant algo and new fancy QC-resistant algo.
So basically QC will have achieved jack shit besides moving everybody to use two algos instead of one.
In 2060 you'll have one device able to use quantum computing to break some messages from 2030, incriminating old senile or long dead politicians, that nobody will give any shit about.
That's the weirdest thing about this whole thing: the only viable QC we hear about is "breaking cryptography" but as soon as that becomes a possibility, we'll all be moving (just like TFA and OpenSSH are showing btw) to QC-resistant algos.
Making QC non-viable.
So... Besides cracking old obsolete message, what the heck can QC be used for?
I mean: what good are those machines going to bring the world, besides cracking old messages nobody cares about and besides making every switch to QC-resistant schemes (like hybrid old+new algos)?
> by 2050 when, my bet, there still won't be any remotely viable QCs
I hate to be that guy, but I'm 52 now and I've been hearing about how Quantum Computing is going to revolutionise everything in the next two years, since I was in primary school and ZX81s were state-of-the-art.
At least a couple of manufacturers offered a practical and afforable(-ish) transputer-based system in the 80s that you could have actually gone out and bought.
Transputers have nothing to do with quantum computing. They're completely classical computers.
Yes, I know. I own some.
They were going to revolutionise absolutely everything to do with computing in just a couple of years, some 40 years ago.
I've been hearing the same thing about quantum computing for about as long.
I will take "Post Quantum Cryptography" seriously when I can buy a quantum microprocessor off the shelf.
Agreed. This looks from the outside like someone read a report, got unnecessarily spooked, and now the rest of the herd is following along.
But it's also very possible that hypothetical report was genuinely concerning. We just haven't seen it or anything like it.
However I'm pretty firmly in the "quantum computing won't be doing anything useful any time soon, if ever" camp, so that definitely colors my opinions. I don't have any particular recent expertise to support that, but I did used to share an office with some serious QC people and go to their talks so... make of my words what you will.
Would anyone downvoting care to explain? I'm genuinely interested in seeing anything that suggests there's either some secret breakthrough (completely plausible, but there's no evidence that I've seen hint of) making quantum computers actually useful, or an argument that they'll be usable by (say) 2050?
Because right now my attitudes are trained by things like this https://algassert.com/post/2500 that explain just why 15 was factored in that famous run of Shor's algorithm and not, say, 21; and why 21 hasn't been factored yet and isn't likely to be any time soon....
I work as a security architect in a major European company. We're currently demanding a full cryptographic inventory of every new product purchased or service built in-house and will start demanding PQC in 2028.
Not because we expect a workable quantum computer by 2030 (current estimates are around 2035-2040), but because stuff survives for decades in large enterprises (especially if it touches hardware in any way. Think OT, think controllers for all kinds of machines).
Now that PQC is standardized, there's no gain not to demand it (it's basically a demand to use a current openSSL/libreSSL/$library), but not demanding it now will cause a major headache once/if quantum computers work.
TLS connection speed matter only for a very tiny niche of applications; those will choose according to their needs. For the general case, it just doesn't matter.
If your threat model includes store-now-decrypt-later, you should have been demanding PQC for years.
Man, the CBOM is such a pain. There is no standardised format yet (let alone efficient tools for crypto discovery), nobody knew what it was one year ago but now every client is asking ours anyway.
CBOM: Cryptography bill of materials.
<https://cyclonedx.org/capabilities/cbom/>
Tell me about it! We've got slightly under 10'000 distinct software assets we are trying to catalogue. There are now a handful of vendors claiming to be able to scan for crypto, but they all suck.
I'm not even there for my employer. I have compiled a list of ~20 different inventory/CBOM solutions and I cannot even fathom how to move to the next step other than picking a few vendors at random and ask them for a demo, but the public info I found was not convincing.
While I can assume these tools do a decent job at crypto asset discovery (a `grep -r "-----BEGIN RSA PRIVATE KEY-----"` is not the hardest product to design), I have no idea what to do for code scanning. CBOMkit and friends do not scan C code, which we actually need.
Google and Cloudflare recently moved their PQC migration timelines forward based on recent research papers in the field. Sources: 1. https://blog.google/innovation-and-ai/technology/safety-secu... 2. https://blog.cloudflare.com/post-quantum-roadmap/
There has been a lot of new stuff over the last few years.
For instance, breaking RSA or ECDSA is requiring much fewer logical qubits than previously thought, and thus fewer physical qubits as well. Progress in error codes, quantum processing etc. made it that in 2019, it was estimated we needed ~20 million noisy qubits to factor RSA 2048. In 2025, we know we need fewer than 1 million. [0]. Some other papers even claim the need of 1000 physical qubits but they rely on a very exotic architecture so I would not consider them feasible.
Progress on the hardware is also continuing, see [1]. Researchers managed to have functional-ish error correction for the first time last year, and experts in the topic are confident that a cryptographically relevant computer will appear in around 15 years.
I personally am less optimistic than the experts (admittedly I am not an expert either), but there is enough activity to get worried for critical infrastructure.
Regarding the factoring issue, as you point out factoring 15 and factoring 21 are two very different tasks. The first one can be used to show that your quantum computer is indeed doing quantum computation; the second will prove that you have a functional error correcting code. If you can factor 21, it is probably only a matter of months/maybe a few years until you factor RSA 2048. As Scott Aaronson said [3], "Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”"
[0] https://arxiv.org/abs/2505.15917
[1] https://sam-jaques.appspot.com/quantum_landscape
[2] https://globalriskinstitute.org/publication/quantum-threat-t...
[3] https://scottaaronson.blog/?p=9665#comment-2029013
Will they decertify previously certified PQC-free products?
Qualification is time-constrained. You are qualified for two to three years. So by 2030, all qualified products will be PQC-free.
> So by 2030, all qualified products will be PQC-free.
You mean the opposite. PQC-free will be blocked, so by 2030 all products will be PQC qualified.
Yes, my bad X).
TBF it's the healtiest approach to it. It's just risk mitigation. Nobody cares about it - there are nice papers to implement it ; just freaking do it.