Comment by BoppreH

5 hours ago

Many people in this thread are skeptical about quantum computers, and that's fair. This migration is a big part of my current job, and even I think that there's a non negligible chance that we won't see commercially available quantum computers anytime soon.

The problem is that we're not trying to predict the exact future, we're hedging against possible developments. If there's a 50/50 chance of quantum computers being widely deployed for cryptoanalysis, then there's a 50% chance of this migration being useless. But you don't want to bet your security on a coin toss! So, we migrate.

That's the unfortunate truth of security, sometimes the protections are never triggered. But you still need them.

There are different types of skepticism when it comes to Quantum Computing (QC). One can be skeptic about its feasibility, namely achieving Fault Tolerant Scalable Quantum Computer (for instance Gil Kalai).

Or, they can be skeptic its applications on the real world.

I am on the second camp, very much. It has mainly two important application areas: Breaking Some Public Key cryptography and Simulating Quantum System.

I think the 1st one is very real, we need to be serious and careful on the migration.

The second area is, I think, extremely overhyped.

One should ask what cases there are for investing in QC that makes financial sense. I can think of couple of areas where quantum effects are important enough to justify this. Better designs for Enzymes and Solid State Batteries. The case for enzyme designs is weakened even more if you check the recent paper by Garnet Chan: https://bsky.app/profile/dulwichquantum.bsky.social/post/3mh...

Unless we see collorobaration between IBM/Google and BYD/CATL/Tesla that will lead to next gen solid state batteries, I would say it wont have substantial impact on the real world. One also has to consider that QC is not the only method to simulation strongly coupled Quantum Systems, there are already other methods, tensor network, Deep Learning based, etc.

Lastly, the QCs will be coming in the future. SO, yhey kind of need to hurry up since current benchmarks for EV batteries are improving every year. There is also the issue of translating lab result into production environment.

All of these factors are eating away the relevance of QCs when it comes to real world applications.

I think we are essentially left with a situation where the only practical application of the technology (QC) is to steal stuff on the internet.

Can you talk about what algorithms you're migrating to?

  • Disclaimer: what follows is my opinion.

    There's a good consensus that for key exchange/encryption (TLS, SSH, age, etc) the way forward is ML-KEM 768 together with some classical algorithm, like X25519. The public keys are larger (1 KB), but that's usually ok unless you're working on very small microcontrollers. And you should migrate quickly because of harvest-now-decrypt-later attacks.

    For signatures, things are harder because there are tradeoffs. Some algorithms have large signatures (10+ KB), others require keeping state and have catastrophic consequences if subkeys are reused. And the systems around it are also more complicated: in a certificate, should you put a classical and a PQC signature together? Or should the PQC signature go in an extension? Should the extension be marked as critical and fail loudly on old clients, or should new clients have a special case to always check it if PQC signature validation is available? Or should we abandon the certificate chains and move to Merkle Tree Certificates[1]?

    So signatures/authentication are still up for debate. Unless your team is on the bleeding edge of either crypto research or security risks, then there's not much to do than wait for better consensus to form.

    [1] https://postquantum.com/security-pqc/googles-merkle-tree-mtc...

    • Your opinion is most welcome. Cheers!

      > And you should migrate quickly because of harvest-now-decrypt-later attacks.

      ...

      > So signatures/authentication are still up for debate. Unless your team is on the bleeding edge of either crypto research or security risks, then there's not much to do than wait for better consensus to form.

      I'm trying, as a layman, to find some not-too-insane middle ground between those contradictions.

      1 reply →