6 ms·

Will you heed my warnings now?

89 points by bwesterb 5mo ago

KaiserPro 5mo ago
Ok, maybe I'm missing something here. So we know that quantum computers hold a real risk of being able to break a lot of encryption. We also know that changing cyphers is hard (because reasons) But what I don't see is what I can practically do now, as either someone who is a CTO/Big Cheese™ or a lowly engineer?
- fastball 5mo ago
  This is what Cloudflare[1] is doing. [1] https://blog.cloudflare.com/post-quantum-roadmap/ https://blog.cloudflare.com/post-quantum-roadmap/
- rolandog 5mo ago
  I think lobby for saner defaults (tip of the hat to Steve Gibson's term "the tyranny of the default"), configuring one's GPG config to mark certain cyphers as insecure (to prevent downgrade attacks)... and have one's (chief) information security officer write those things down as policy and maybe have a yearly onboarding workshop teaching people why it's important.
- MattPalmer1086 5mo ago
  If you're a CTO, have a post quantum strategy: know what crypto you use and where it is, plan to migrate to post quantum secure ciphers over the next decade or so, or sooner if possible. If you're a lowly engineer, not very much unless you're specifically selecting technologies with crypto. In which case crypto agility (being able to switch out existing crypto when needed) is a good property to look for.
- weddpros 5mo ago
  TLS can already be setup to avoid store-now-decrypt-later PQC issues. That's available today, and should be implemented. Use https://sslboard.com https://sslboard.com to inventory all your external TLS infrastructure and check for PQC readiness (creator here).
- BoppreH 5mo ago
  > But what I don't see is what I can practically do now, as either someone who is a CTO/Big Cheese™ or a lowly engineer? Migrate! The major TLS and OpenSSH applications already support PQC, for example. 1. Make sure you have the required dependencies (e.g., openssl 3.5+ is when a lot of PQC algorithms got support). 2. Make sure the client/server software is up to date (this might be all that's needed, e.g., OpenSSH 10.0+ enables PQC in-transit encryption by default, and so does Chrome 131+). 3. Enable PQC support in the configuration (e.g., "ssl_ecdh_curve X25519MLKEM768;" in Nginx). If you are the developer of anything that's explicitly using RSA or ECC (or god forbid Diffie-Hellman), you can also migrate your own software, or at least make the algorithm selectable at initialization time instead of hardcoded. If you have vendors, ask them for their PQC migration roadmaps. Note that with encrypted data you want to protect yourself against attackers that are capturing data today and waiting to break it in the future (Harvest-Now, Decrypt-Later). So migrating encryption is more urgent than migrating authentication.
- beloch 5mo ago
  The most important thing to realize about cryptography is that, for most methods short of a Vernam cipher or quantum key distribution, coded messages need to be treated as published with delay. Cipher text can be archived today and attacked years from now with currently undeveloped, unknown, or unpredicted resources/algorithms. Sure, perhaps nobody archived the cipher text and you're fine. You don't know that for sure. Your methods may be very strong but, if they're not provably immune to attack, you also don't know what the delay before publication truly is. It might be a very long time. It might not. If you're transmitting credit card info that changes every few years and can be changed on demand, that's no big deal. If you're transmitting information that will remain sensitive for decades, the time to look for methods that would stand up to quantum computing was years ago. However, today is still better than years in the future. At the very least, you can choose what to send in encrypted form over public networks and what not to send. There are people who will scoff at the notion of quantum computing ever developing to the point where it can make an impact. There are people who scoff at the effort and expense of QKD or good ol' spooks carrying briefcases full of one-time PADs. You might be right to listen to them. You might not be. It's a risk. Whether you, or your organization, can tolerate that risk is entirely dependent on you and yours.
  - Tyyps 5mo ago
    About QKD: https://arxiv.org/abs/1803.04520 https://arxiv.org/abs/1803.04520
    - beloch 5mo ago
      Did this pass peer review somewhere?
  - bwesterb 5mo ago
    QKD is cool and all, but it just doesn't scale to the whole Internet. https://blog.cloudflare.com/you-dont-need-quantum-hardware/ https://blog.cloudflare.com/you-dont-need-quantum-hardware/
- bwesterb 5mo ago
  Where available, you can migrate. Even if PQ is not yet available it helps to: 1. Make sure your dependencies are up to date. Move to a recent version of your crypto libraries. 2. Make sure your server can install multiple certificates: you'll need that unless you control all your clients. 3. Automate certificate issuance as far as possible. Also, what you can do now is to run the following wargame: assume the CRQC arrived. What's the business impact? For the migration itself I see three parallel streams. 1. Main push of straight-forward cases (TLS, etc.) Might need to wait a bit for software support. 2. Hard cases: crypto baked into hardware; custom protocols; keys in tight spaces (JWT in URLs); etc. You need to bubble those up soon to make decisions on how to fix them. 3. External dependencies. Barely any vendor has a PQ roadmap, so asking now is probably early, but you can figure out what to do if they don't get their stuff ready in time.
FartyMcFarter 5mo ago
> the Shor of Damocles Perfect.
AndrewStephens 5mo ago
Aaronson know his stuff but I am not sure he hasn’t considered the fact that, in this current hype cycle, the quantum researchers breathlessly reporting to him on a breakthrough just around the corner are just lying to him and themselves. I have been hearing about one more technical hurdle to solve before quantum algorithms become feasible since before I graduated. That was in 1996.
- chii 5mo ago
  quantum computers will flourish the same day that fusion does.
- bradley13 5mo ago
  This is true, practical quantum computing is always "just a couple of years away". At the same time, moving to more secure encryption really isn't difficult. How many times have algorithms been deprecated over the past 20 or so years? It's time to do it again. Let's just make sure that the NSA hasn't worked in any backdoors. At latest since Snowdon, anything they work on is suspect.
  - AshamedCaptain 5mo ago
    And in the process immediately convert huge numbers of devices into ewaste. Then check the excuse calendar again for tomorrow's reason to deprecate yet another batch of "legacy" ciphers from openSSL.
    - FartyMcFarter 5mo ago
      The sooner we start making devices ready for better encryption systems, the fewer devices will be wasted.
      - AshamedCaptain 5mo ago
        No, because there always are "better encryption systems", whether for good reasons or not that's another story.
notarobot123 5mo ago
"The Shor of Damocles" - what a metaphor. I thought it was a typo at first but wikipedia explained: The Sword of Damocles is an ancient Greek moral anecdote, an allusion to the imminent and ever-present peril faced by those in positions of power. Shor's algorithm is a quantum algorithm for finding the prime factors of an integer
- Obscurity4340 5mo ago
  It applies to those subject to a capricious arbitrary power as well. Like living under a shitty parent, the same threat(s) they settle on to control them becomes the dangling Sword till its forecefully removed and they are neutered
amelius 5mo ago
Tl;dr: > if quantum computers start breaking cryptography a few years from now, don’t you dare come to this blog and tell me that I failed to warn you. This post is your warning.
- dwedge 5mo ago
  If quantum computers broke cryptography I think going to some guy's blog and complaining that he failed to warn me would be pretty low down on my todo list
Ardren 5mo ago
> Shor of Damocles What is the biggest number factored using Shor's algorithm? Last time I looked it was very unimpressive. Edit: It's gotten worse. 21 from 2012. "Replication of Quantum Factorisation Records with an 8-bit Home Computer, an Abacus, and a Dog" say the factorization of 35 in 2019 actually failed. https://eprint.iacr.org/2025/1237 https://eprint.iacr.org/2025/1237
- FartyMcFarter 5mo ago
  I said this about LLMs a few years ago, and now here we are.
  - L-four 5mo ago
    Yeah 70 years ago right.
- sanxiyn 5mo ago
  I will let Scott Aaronson speak. (See https://scottaaronson.blog/?p=9668 https://scottaaronson.blog/?p=9668) > Sometimes these days, I'll survey the spectacular recent progress in fault-tolerance, 2-qubit gate fidelities, programmable hundred-qubit systems, etc., only to be answered with a sneer: "What's the biggest number that Shor's algorithm has factored? Still 15 after all these years? Haha, apparently the emperor has no clothes!" I've commented that this is sort of like dismissing the Manhattan Project as hopelessly stalled in 1944, on the ground that so far it hasn't produced even a tiny nuclear explosion... If there's a reason why you think it can't work beyond a certain scale, say so. But don't fixate on one external benchmark and ignore everything happening under the hood, if the experts are telling you that under the hood is where all the action now is, and your preferred benchmark is only relevant later.
  - toxik 5mo ago
    I talked to a guy who did his doctoral degree on quantum computing and he was not worried at all. In fact he thought it was wildly overhyped, and like cold fusion, self driving cars, or string theory, always just around the corner. Just give us five more years and another grant, please.
sehansen 5mo ago
As a software engineer with a good amount of freedom to choose what tools I want to use, what can I do presently to move towards post-quantum cryptography? AFAIK the hashes and symmetric cyphers that are in wide use are already resistant, leaving mainly public-key cryptography as the problem. Is there, for instance, a drop in replacement for `ssh-keygen -t ed25519`?
- alephnerd 5mo ago
  It's still being implemented or defined. The worry about "harvest and decrypt" in a 5 year timeframe is primarily from a nation state/natsec perspective. If you are being targeted by a nation state as a line level engineer, harvest and decrypt is the least of your worries.
  - i_think_so 5mo ago
    I am reminded of a certain comedian who lost his job hosting an awards ceremony because he had once said something on stage that people didn't like.... ...8 years previously.[1] Long, long ago in a datacenter far away, breaking 3DES used to be the province of expensive bespoke hardware owned by only the elite nation states. Today it is so trivial that the gpu in your second hand laptop can do it "at scale". 5 years ago ChatGPT was a wet dream. We should be very conservative in our planning where future security is concerned. The only thing we can be sure of is that Murphy's Law is looking for every chance to make us look foolish. [1] https://www.bbc.com/news/entertainment-arts-46479017 https://www.bbc.com/news/entertainment-arts-46479017
    - MattPalmer1086 5mo ago
      As far as I know, cracking 3DES is still not trivial, and requires a very large number of operations and/or a very large amount of data. But can just about be done in some situations. If you have any link to trivially cracking it on your second hand laptop and doing it at scale, would be very interested.
      - 5mo ago
endymion-light 5mo ago
I'm sure eventually i'll eat my words - but Quantum still seems like a massive marketing gimmick. The technology itself is incredibly interesting, but it feels as if CERN began advertising itself as a marketing stunt - there's just something about the way I see quantum marketed + advertised right now that doesn't seem to align with reality.
- Razengan 5mo ago
  > * it feels as if CERN began advertising itself as a marketing stunt* Quantum AI harvesting antimatter
  - endymion-light 5mo ago
    I suppose in spirit of the article - it's as if the manhattan project in 1944 was telling the world that theoretically it's 6-12 months away from igniting the entire upper atmosphere.
YouWhy 5mo ago
Re the "Manhattan project in 1944" argument - I am very cautious about the "modulo engineering scaling" carve-out -- unlike the uranium manufacturing pipeline of World War 2, that involved massively scaling up a known process, on the face of it there's no uncontroversial process/architecture to scale up in this case. On the face of it, even relatively "point-target" goals of this kind could take many decades if at all; GaN for blue diodes come in mind as an example of a field that was stuck for a generation -- until it wasn't.
- codethief 5mo ago
  > I am very cautious about the "modulo engineering scaling" carve-out As OP said elsewhere[0, 1]: > 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?” In other words (IIUC): Some problems (here: scaling fault tolerance) seem to be easier than others. [0]: https://scottaaronson.blog/?p=9665#comment-2029013 https://scottaaronson.blog/?p=9665#comment-2029013 [1]: See also https://news.ycombinator.com/item?id=47959531 https://news.ycombinator.com/item?id=47959531 for a very similar quote.
brador 5mo ago
Sounding the alarm while presenting no data or science, as a member of the National academy of sciences, is doing a disservice to the position, to science, to the self. Show the data, the charts, let people decide for themselves.
- codethief 5mo ago
  > Sounding the alarm while presenting no data or science One needs to read OP's blog post in the context of his other posts from the last couple months (many of which have been discussed here on HN in one way or another), where he does discuss the science.
  - nh23423fefe 5mo ago
    Demanding information one won't read or understand.
marsven_422 5mo ago
[dead]
boh 5mo ago
People are starting to catch on to the AI scare mongering, let the quantum computer scare mongering begin. We should probably start giving these companies lots of money lest other countries beat us to it.
BoppreH 5mo 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.
- i_think_so 5mo ago
  Can you talk about what algorithms you're migrating to?
  - BoppreH 5mo ago
    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-https/ https://postquantum.com/security-pqc/googles-merkle-tree-mtc...
i_think_so 5mo ago
Does djb ever frequent HN? Can we summon him with the correct incantations? I'd really like to know what his current work on the subject entails, but when I try googling his stuff all I find are years-old papers, more recent meta discussion, and him making a few comments about other peoples' work. I was sure that by now he'd have at least collaborated on some avant-garde PQ algo that was as different from the NSA approved stuff as chacha20-poly1305 was from AES. I was hoping for a PQ-NaCl folks would be using soon, not the libpqcrypto that seems to lack traction among devs (for reasons I do not understand). I am disappoint. (It's probably all tucked away in some corner of the web that a layman like me will never find. Sigh.) Edit: Hah! I gave up on looking for papers or repos and decided to just read his blog instead. Well would'ya look at that! It's non-stop PQ ranting of the kind we've come to love and cherish from DJB. No new repos or code with his imprimatur that I can see so far but better than I was expecting. Looks like I've got some reading to do.... I should have subscribed to his rss feed years ago. And his "microblog" too! https://microblog.cr.yp.to/ https://microblog.cr.yp.to/
projektfu 5mo ago
My only concern is that in the rush to implement PQC everywhere, less well-tested/battle-hardened algorithms get used and everything becomes insecure to someone who has found the master key.

89 points by bwesterb 5mo ago

Ok, maybe I'm missing something here. So we know that quantum computers hold a real risk of being able to break a lot of encryption. We also know that changing cyphers is hard (because reasons) But what I don't see is what I can practically do now, as either someone who is a CTO/Big Cheese™ or a lowly engineer?

fastball 5mo ago
This is what Cloudflare[1] is doing. [1] https://blog.cloudflare.com/post-quantum-roadmap/ https://blog.cloudflare.com/post-quantum-roadmap/
rolandog 5mo ago
I think lobby for saner defaults (tip of the hat to Steve Gibson's term "the tyranny of the default"), configuring one's GPG config to mark certain cyphers as insecure (to prevent downgrade attacks)... and have one's (chief) information security officer write those things down as policy and maybe have a yearly onboarding workshop teaching people why it's important.
MattPalmer1086 5mo ago
If you're a CTO, have a post quantum strategy: know what crypto you use and where it is, plan to migrate to post quantum secure ciphers over the next decade or so, or sooner if possible. If you're a lowly engineer, not very much unless you're specifically selecting technologies with crypto. In which case crypto agility (being able to switch out existing crypto when needed) is a good property to look for.
weddpros 5mo ago
TLS can already be setup to avoid store-now-decrypt-later PQC issues. That's available today, and should be implemented. Use https://sslboard.com https://sslboard.com to inventory all your external TLS infrastructure and check for PQC readiness (creator here).
BoppreH 5mo ago
> But what I don't see is what I can practically do now, as either someone who is a CTO/Big Cheese™ or a lowly engineer? Migrate! The major TLS and OpenSSH applications already support PQC, for example. 1. Make sure you have the required dependencies (e.g., openssl 3.5+ is when a lot of PQC algorithms got support). 2. Make sure the client/server software is up to date (this might be all that's needed, e.g., OpenSSH 10.0+ enables PQC in-transit encryption by default, and so does Chrome 131+). 3. Enable PQC support in the configuration (e.g., "ssl_ecdh_curve X25519MLKEM768;" in Nginx). If you are the developer of anything that's explicitly using RSA or ECC (or god forbid Diffie-Hellman), you can also migrate your own software, or at least make the algorithm selectable at initialization time instead of hardcoded. If you have vendors, ask them for their PQC migration roadmaps. Note that with encrypted data you want to protect yourself against attackers that are capturing data today and waiting to break it in the future (Harvest-Now, Decrypt-Later). So migrating encryption is more urgent than migrating authentication.
beloch 5mo ago
The most important thing to realize about cryptography is that, for most methods short of a Vernam cipher or quantum key distribution, coded messages need to be treated as published with delay. Cipher text can be archived today and attacked years from now with currently undeveloped, unknown, or unpredicted resources/algorithms. Sure, perhaps nobody archived the cipher text and you're fine. You don't know that for sure. Your methods may be very strong but, if they're not provably immune to attack, you also don't know what the delay before publication truly is. It might be a very long time. It might not. If you're transmitting credit card info that changes every few years and can be changed on demand, that's no big deal. If you're transmitting information that will remain sensitive for decades, the time to look for methods that would stand up to quantum computing was years ago. However, today is still better than years in the future. At the very least, you can choose what to send in encrypted form over public networks and what not to send. There are people who will scoff at the notion of quantum computing ever developing to the point where it can make an impact. There are people who scoff at the effort and expense of QKD or good ol' spooks carrying briefcases full of one-time PADs. You might be right to listen to them. You might not be. It's a risk. Whether you, or your organization, can tolerate that risk is entirely dependent on you and yours.
- Tyyps 5mo ago
  About QKD: https://arxiv.org/abs/1803.04520 https://arxiv.org/abs/1803.04520
  - beloch 5mo ago
    Did this pass peer review somewhere?
- bwesterb 5mo ago
  QKD is cool and all, but it just doesn't scale to the whole Internet. https://blog.cloudflare.com/you-dont-need-quantum-hardware/ https://blog.cloudflare.com/you-dont-need-quantum-hardware/
bwesterb 5mo ago
Where available, you can migrate. Even if PQ is not yet available it helps to: 1. Make sure your dependencies are up to date. Move to a recent version of your crypto libraries. 2. Make sure your server can install multiple certificates: you'll need that unless you control all your clients. 3. Automate certificate issuance as far as possible. Also, what you can do now is to run the following wargame: assume the CRQC arrived. What's the business impact? For the migration itself I see three parallel streams. 1. Main push of straight-forward cases (TLS, etc.) Might need to wait a bit for software support. 2. Hard cases: crypto baked into hardware; custom protocols; keys in tight spaces (JWT in URLs); etc. You need to bubble those up soon to make decisions on how to fix them. 3. External dependencies. Barely any vendor has a PQ roadmap, so asking now is probably early, but you can figure out what to do if they don't get their stuff ready in time.

FartyMcFarter 5mo ago

> the Shor of Damocles Perfect.

AndrewStephens 5mo ago

Aaronson know his stuff but I am not sure he hasn’t considered the fact that, in this current hype cycle, the quantum researchers breathlessly reporting to him on a breakthrough just around the corner are just lying to him and themselves. I have been hearing about one more technical hurdle to solve before quantum algorithms become feasible since before I graduated. That was in 1996.

chii 5mo ago
quantum computers will flourish the same day that fusion does.
bradley13 5mo ago
This is true, practical quantum computing is always "just a couple of years away". At the same time, moving to more secure encryption really isn't difficult. How many times have algorithms been deprecated over the past 20 or so years? It's time to do it again. Let's just make sure that the NSA hasn't worked in any backdoors. At latest since Snowdon, anything they work on is suspect.
- AshamedCaptain 5mo ago
  And in the process immediately convert huge numbers of devices into ewaste. Then check the excuse calendar again for tomorrow's reason to deprecate yet another batch of "legacy" ciphers from openSSL.
  - FartyMcFarter 5mo ago
    The sooner we start making devices ready for better encryption systems, the fewer devices will be wasted.
    - AshamedCaptain 5mo ago
      No, because there always are "better encryption systems", whether for good reasons or not that's another story.

notarobot123 5mo ago

"The Shor of Damocles" - what a metaphor. I thought it was a typo at first but wikipedia explained: The Sword of Damocles is an ancient Greek moral anecdote, an allusion to the imminent and ever-present peril faced by those in positions of power. Shor's algorithm is a quantum algorithm for finding the prime factors of an integer

Obscurity4340 5mo ago
It applies to those subject to a capricious arbitrary power as well. Like living under a shitty parent, the same threat(s) they settle on to control them becomes the dangling Sword till its forecefully removed and they are neutered

amelius 5mo ago

Tl;dr: > if quantum computers start breaking cryptography a few years from now, don’t you dare come to this blog and tell me that I failed to warn you. This post is your warning.

dwedge 5mo ago
If quantum computers broke cryptography I think going to some guy's blog and complaining that he failed to warn me would be pretty low down on my todo list

Ardren 5mo ago

> Shor of Damocles What is the biggest number factored using Shor's algorithm? Last time I looked it was very unimpressive. Edit: It's gotten worse. 21 from 2012. "Replication of Quantum Factorisation Records with an 8-bit Home Computer, an Abacus, and a Dog" say the factorization of 35 in 2019 actually failed. https://eprint.iacr.org/2025/1237 https://eprint.iacr.org/2025/1237

FartyMcFarter 5mo ago
I said this about LLMs a few years ago, and now here we are.
- L-four 5mo ago
  Yeah 70 years ago right.
sanxiyn 5mo ago
I will let Scott Aaronson speak. (See https://scottaaronson.blog/?p=9668 https://scottaaronson.blog/?p=9668) > Sometimes these days, I'll survey the spectacular recent progress in fault-tolerance, 2-qubit gate fidelities, programmable hundred-qubit systems, etc., only to be answered with a sneer: "What's the biggest number that Shor's algorithm has factored? Still 15 after all these years? Haha, apparently the emperor has no clothes!" I've commented that this is sort of like dismissing the Manhattan Project as hopelessly stalled in 1944, on the ground that so far it hasn't produced even a tiny nuclear explosion... If there's a reason why you think it can't work beyond a certain scale, say so. But don't fixate on one external benchmark and ignore everything happening under the hood, if the experts are telling you that under the hood is where all the action now is, and your preferred benchmark is only relevant later.
- toxik 5mo ago
  I talked to a guy who did his doctoral degree on quantum computing and he was not worried at all. In fact he thought it was wildly overhyped, and like cold fusion, self driving cars, or string theory, always just around the corner. Just give us five more years and another grant, please.

sehansen 5mo ago

As a software engineer with a good amount of freedom to choose what tools I want to use, what can I do presently to move towards post-quantum cryptography? AFAIK the hashes and symmetric cyphers that are in wide use are already resistant, leaving mainly public-key cryptography as the problem. Is there, for instance, a drop in replacement for `ssh-keygen -t ed25519`?

alephnerd 5mo ago
It's still being implemented or defined. The worry about "harvest and decrypt" in a 5 year timeframe is primarily from a nation state/natsec perspective. If you are being targeted by a nation state as a line level engineer, harvest and decrypt is the least of your worries.
- i_think_so 5mo ago
  I am reminded of a certain comedian who lost his job hosting an awards ceremony because he had once said something on stage that people didn't like.... ...8 years previously.[1] Long, long ago in a datacenter far away, breaking 3DES used to be the province of expensive bespoke hardware owned by only the elite nation states. Today it is so trivial that the gpu in your second hand laptop can do it "at scale". 5 years ago ChatGPT was a wet dream. We should be very conservative in our planning where future security is concerned. The only thing we can be sure of is that Murphy's Law is looking for every chance to make us look foolish. [1] https://www.bbc.com/news/entertainment-arts-46479017 https://www.bbc.com/news/entertainment-arts-46479017
  - MattPalmer1086 5mo ago
    As far as I know, cracking 3DES is still not trivial, and requires a very large number of operations and/or a very large amount of data. But can just about be done in some situations. If you have any link to trivially cracking it on your second hand laptop and doing it at scale, would be very interested.
    - 5mo ago

endymion-light 5mo ago

I'm sure eventually i'll eat my words - but Quantum still seems like a massive marketing gimmick. The technology itself is incredibly interesting, but it feels as if CERN began advertising itself as a marketing stunt - there's just something about the way I see quantum marketed + advertised right now that doesn't seem to align with reality.

Razengan 5mo ago
> * it feels as if CERN began advertising itself as a marketing stunt* Quantum AI harvesting antimatter
- endymion-light 5mo ago
  I suppose in spirit of the article - it's as if the manhattan project in 1944 was telling the world that theoretically it's 6-12 months away from igniting the entire upper atmosphere.

YouWhy 5mo ago

Re the "Manhattan project in 1944" argument - I am very cautious about the "modulo engineering scaling" carve-out -- unlike the uranium manufacturing pipeline of World War 2, that involved massively scaling up a known process, on the face of it there's no uncontroversial process/architecture to scale up in this case. On the face of it, even relatively "point-target" goals of this kind could take many decades if at all; GaN for blue diodes come in mind as an example of a field that was stuck for a generation -- until it wasn't.

codethief 5mo ago
> I am very cautious about the "modulo engineering scaling" carve-out As OP said elsewhere[0, 1]: > 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?” In other words (IIUC): Some problems (here: scaling fault tolerance) seem to be easier than others. [0]: https://scottaaronson.blog/?p=9665#comment-2029013 https://scottaaronson.blog/?p=9665#comment-2029013 [1]: See also https://news.ycombinator.com/item?id=47959531 https://news.ycombinator.com/item?id=47959531 for a very similar quote.

brador 5mo ago

Sounding the alarm while presenting no data or science, as a member of the National academy of sciences, is doing a disservice to the position, to science, to the self. Show the data, the charts, let people decide for themselves.

codethief 5mo ago
> Sounding the alarm while presenting no data or science One needs to read OP's blog post in the context of his other posts from the last couple months (many of which have been discussed here on HN in one way or another), where he does discuss the science.
- nh23423fefe 5mo ago
  Demanding information one won't read or understand.

marsven_422 5mo ago

[dead]

boh 5mo ago

People are starting to catch on to the AI scare mongering, let the quantum computer scare mongering begin. We should probably start giving these companies lots of money lest other countries beat us to it.

BoppreH 5mo 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.

i_think_so 5mo ago
Can you talk about what algorithms you're migrating to?
- BoppreH 5mo ago
  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-https/ https://postquantum.com/security-pqc/googles-merkle-tree-mtc...

i_think_so 5mo ago

Does djb ever frequent HN? Can we summon him with the correct incantations? I'd really like to know what his current work on the subject entails, but when I try googling his stuff all I find are years-old papers, more recent meta discussion, and him making a few comments about other peoples' work. I was sure that by now he'd have at least collaborated on some avant-garde PQ algo that was as different from the NSA approved stuff as chacha20-poly1305 was from AES. I was hoping for a PQ-NaCl folks would be using soon, not the libpqcrypto that seems to lack traction among devs (for reasons I do not understand). I am disappoint. (It's probably all tucked away in some corner of the web that a layman like me will never find. Sigh.) Edit: Hah! I gave up on looking for papers or repos and decided to just read his blog instead. Well would'ya look at that! It's non-stop PQ ranting of the kind we've come to love and cherish from DJB. No new repos or code with his imprimatur that I can see so far but better than I was expecting. Looks like I've got some reading to do.... I should have subscribed to his rss feed years ago. And his "microblog" too! https://microblog.cr.yp.to/ https://microblog.cr.yp.to/

projektfu 5mo ago

My only concern is that in the rush to implement PQC everywhere, less well-tested/battle-hardened algorithms get used and everything becomes insecure to someone who has found the master key.