But that's a miss, it's like one of those Neal Stephenson moments where the creator is using the right language (so it's not like reading William Gibson who clearly has no idea and knows it - he's going for the emotional feel not the technology) but they don't understand what's actually going on.

OTP is in theory the correct choice if you don't have working symmetric cryptography but in fact the "Quantum computer" approach barely dents our symmetric cryptography.

I've written about this before, DES was standardized in 1977, almost 50 years ago and you might think "Well but DES is broken". Yes, DES broke exactly the way it was designed to. Literally nothing went wrong, when it was standardized we knew the keys are too small (yup, you can break it by trying all the keys) and the blocks are too small (yup, you can "just" make duplicate blocks) and it was broken by leaning on these weaknesses with huge fast modern computers.

AES is an entirely different cryptosystem, but the two most important choices were that the keys are big enough (128-bit or 256-bit commonly) and the blocks are too (128 bits). And those may seem like a small upgrade, only 2-4x as big, who cares? Well those are bit lengths so that's an exponential increase, and your quantum computer barely helps (assuming it magically is the same price rather than incredibly expensive). It is not physically practical for the necessary computation to be done, AES is broken only if there's some mathematical backdoor we didn't know about.

"We'll crack AES with a quantum computer" is a Hollywood movie plot, it's not a thing that makes any actual sense.

[Edited: I wrote "Bruce Sterling" but I meant "William Gibson", I apologise to both people for muddling them, though not for my opinion]

> a near term risk we are planning for

I'd argue it's closer to a cheap insurance, just in case.

Take the encryption of a TLS connection itself, for example: you want to protect against a possible "store now, decrypt later" attack on your connection, 60 years from now, by an attacker with an NSA-level budget. Even if you judge the probability of it happening as "exceedingly unlikely", migrating to a hybrid scheme is a no-loss scenario, so it would be silly not to. In a way it's almost a Pascal's Wager.

And then there's of course the NSA itself, who are heavily pushing for post-quantum-only schemes and trying to suppress the hybrid schemes as they almost certainly have weaknesses for some of those new PQ schemes already lying around.

If we take near term to mean “while any of the participants in this thread are still alive”, I think we’re going to be safe for a while.

https://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf

This is the second time in my life I’ve heard of this book. It was a wickedly weird book. I think I was 1/3rd through it before I figured out the plurality of the characters.

I've always thought creating an ssh-otp should be easy to implement.

(meaning xor the packets themselves with a huge bundle of random data duplicated at each side, and never re-used)

But I think it would probably still qualify as a munition and have export restrictions.

In terms of actually doing it, it's still very remote, but not as remote as it would have to be for us to completely ignore it. And the NSA has massive data centers full of hard drives storing our encrypted internet traffic.

That sounds a lot like Shamir Secret Sharing Algorithm similar to unsealing / sealing HashiCorp Vault.

I did read the books 20 years ago and forgot this aspect of the story

> The pads are split into three pieces that are XORed to create the actual pad to reduce risk of compromise.

Thus creating a two-time pad, which is completely insecure…

Is there any value in first encrypting with a battle tested algorithm, and then encrypt again with the new algorithm?

Yes, many of the problems from CT are fixed. I wouldn't call it a "broken mess" though, as it has been relatively effective at detecting various problems, and to my knowledge hasn't been compromised.

There are no SCTs, which were a compromise to get CT shipped. Each Merkle Tree Certificate has an actual inclusion proof in it.

CT has multiple independent logs, and requires certs to be logged to 2+ of them. With MTC, you have one issuing log, along with signatures from other "witnesses" which monitor and mirror log integrity. Those co-signatures are validated when checking the certificate.

Thus the witness network makes it much harder for logs to fork, as you can't present a forked view to just the client. You also need to present it to a witness. And it'll be much easier for folks to check all the witnesses are in sync.

Monitoring the MTC logs will be easier than CT, as they'll actually be smaller than CT for a few reasons. At least for the initial version, there won't be a better way to monitor for mis-issued certificates for a particular domain than linear scanning all certificates, but that's a problem being worked on for both CT and MTC, called "verifiable indexes".

Signatures aren't as urgent to replace as encryption keys are. You can wait until someone is about to build a quantum computer, then change all your signatures. Encrypted data is more critical because the NSA's going to store all internet traffic for centuries if it thinks it can decrypt it later.

There's an IETF RFC draft for mldsa-44 keys for OpenSSH. https://datatracker.ietf.org/doc/draft-rpe-ssh-mldsa

I'm not aware if it has any real traction, but that's what I found with a quick search.

The downside is that to get the size optimization, TLS servers will get moderately more complicated (they'll need to have multiple MTC certificates configured and select the right one depending on the client's state), and TLS clients will get considerably more complicated (they'll need to continuously download landmarks for each CA out-of-band from a trusted source).

I expect many non-browser TLS clients won't support the small landmark-relative certificates, because there isn't a clear party to operate the landmark distribution service (Chrome has Google, and Firefox has Mozilla, but who does curl have?). I'm also worried that support will be lacking in open source TLS servers, though that's a more tractable problem. Consequentially, I expect the large standalone certificates to be quite common outside of connections between browsers and CDNs.

I too was wondering how they feel about the potential downsides which is not really mentioned.

The main downside is shifting from inline validation to out-of-band state syncing. For handshakes to stay small, browsers must constantly cache fresh "landmarks." If a device has been offline and hits a flaky hotel captive portal, it lacks these landmarks and triggers a fallback with massive inline ML-DSA signatures—bloating the handshake to 10KB+ exactly when the network is at its worst. It essentially turns a crypto size problem into a browser background syncing challenge.

There is nothing answered in there. Just "It'll be fine" and vague pointing at unrelated ecc vulnerabilities in some libs. It totally lacks any rational arguments.

Great question! Of course, we'll continue to provide more information as we firm up more details. This is an area that's not locked down yet, but I can give a sneak preview of what it might look like.

We expect batches to be produced quickly, on the same order of magnitude as current CT logs - somewhere in the 0.5s to 5 second range. This is an existing problem since (at least some) CT logs do the same batched behaviour.

Now, there is a catch with MTCA: That gets you a "standalone" certificate, which works just like a certificate does today. But it's big, still. To get the new, small certificates (landmark-relative), you will have to wait for the next landmark. Based on current planning and discussions with Chrome, we expect that to be hourly for short-lived certs, and 4 hours for longer-lived certificates.

So you'll get a big cert instantly, but you might have to wait an hour or 4 to get a certificate. So your new website can be online quickly, but with some downsides until you get the small landmark-relative cert.

(I work at Let's Encrypt)

You'll be able to immediately use use a "standalone certificate" while waiting for the batch to be created. The tradeoff is that the standalone certificate will have multiple huge ML-DSA signatures.

They can't address it because nobody knows the answer yet. That's why their plans https://letsencrypt.org/2026/06/03/pq-certs#our-plans are to work with experts to solve the engineering challenges in the coming years, rather than announce a gift-wrapped solution today.

If this fear of yours is particularly poignant, I invite you to share it with the forum so they have it in writing. It makes it easier for them to consider it as they work on a solution.

Much love, from the NSA!

You are right in that there are cases where signatures need to be quantum-safe, and they need to be urgently replaced because they will be long-lived.

But WebPKI, which letsencrypt is concerned with, doesn't need long-lived signatures at all. TLS connections live a few days at the most, that's how long the connection signatures have to hold up. The only thing that really needs some lifetime are CA certificate signatures and the CA keys themselves. And even for those CA certificates currently, CRQCs won't be a problem before they expire. And browser update cycles are quick enough that new CA certificates aren't that much of a problem anymore.

> Refreshing! Not wanting to be the "told you so" guy,

> This is a problem that I have met so many times talking with people: they parrot the "Harvest-Now-Decrypt-Later is the only urgent problem, signatures can wait" mantra, and this piece of misinformation has spread so much that even AI repeats it (because it has been trained on open data, where the overwhelming sentiment has been following this trend), thereby reinforcing the problem. Ask Claude/ChatGPT/Gemini about the problem, and they will invariably tell you that signatures are less urgent because theyr are not subjective to retroactive compromise.

I can't speak to public sentiment, but the stance I've held for years was roughly:

HNDL is more urgent because people are already encrypting messages today that could be decrypted in the future if a quantum computer is ever built in the foreseeable future, and that harms their privacy for the entirety of human history until PQC is rolled out.

That's not the same as "authentication doesn't matter at all". It was, if you must pick a problem to solve today, this one will stop the bleeding sooner.

But they were always both important to solve. The question was whether we could delay PQ auth until better signature algorithms were deployed. The Google/Cloudflare 2029 decision signaled to the rest of us: "No, we need to start the migration now."

there is no even conjectured candidate for a backdoor in the standardized PQ schemes. This is different from other backdoors in the past, for example

1. for DUAL_EC_DRBG, the fact that it could hold a backdoor was understood quite early on

2. The S-box in the russian block ciphers Kuznyechik and Streebog was said to be randomly generated, but it was discovered to have extremely particular structure, which makes it exceedingly unlikely to be randomly generated.

Note that both of these "warning signs" are able to be seen even without understanding yet how to exploit them. To this day we do not know if Kuzynyechik and Streebog are backdoored (though it seems exceedingly likely).

Another point worth mentioning is that the design underlying ML-KEM could be instantiated in a way that would admit a backdoor. Very roughly, we would instantiate a "ML-KEM lattice", akin to how DLOG-based schemes instantiate DLOG groups (e.g. curve 25519, etc). This ML-KEM lattice could plausibly be attacked with a precomputation attack, akin to things like the LogJam attack against finite-field DH (there are even more fun things you can do if this standardized ML-KEM is just e.g. written down, rather than generated akin to a "nothing up my sleeve" number).

ML-KEM was specifically designed around this issue, and instead freshly samples a ML-KEM lattice for each exchanged key. Fortunately, it is quite easy to do this efficiently and securely for ML-KEM (freshly sampling a DLOG group to work in is neither efficient nor secure for elliptic-curve based cryptography).

> and very likely backdoored post-quantum algorithms

Citation needed

Here's mine: https://keymaterial.net/2025/11/27/ml-kem-mythbusting/

The capabilities of quantum computing, in theory, are pretty well known. There's basically a few extra operations which can be done efficiently on it and so that can be built into the threat model, even if no-one's built a quantum computer yet.

(Of course, basically all encryption, especially asymmetric encryption, is predicated on there not being some as-yet-undiscovered exploitable structure to the mathematics on which it is built. Modern cryptography, AFAIK, tends to have some decent arguments for why this is not expected to be the case, but it's never completely proven top-to-bottom outside of fairly niche/trivial cases. It's always in principle possible that someone discovers an attack on these new algorithms, classical or quantum)

In addition to the other fine answers, I personally find the additional operations that quantum computers enable to be surprisingly inapplicable to a lot of real problems. It's really kind of unimpressive when you dig down into it. It is not a revolution of computing as we know it, it's a very, very expensive accelerator card for a few niche problems. Neat for people who have those problems. But if "cracking cryptography" wasn't one of those problems I'm not sure it would have the popular attention it does.

I think there is a sense in which we have a historical accident that has make quantum computers sound bigger than they are, in that we ended up with "factoring prime numbers" being the first thing we had to make practical encryption out of, and by what is from a human perspective mostly a coincidence, it so happens that quantum computers may be really good at that. But the problem is that quantum computers happen to be good at factorizing that is the problem, not that quantum computers are somehow "good at breaking encryption". It seams to me that in some sense "post-quantum computing" is actually "all practical encryption schemes except those based on factoring large numbers". Breaking large prime number-based schemes is the exception that QC happens to be good at, not the rule.

By this standard, there is no current encryption method (except for pre-shared one time pads when used correctly) that is known to be unbreakable. For example, it is not proven that prime factoring can't be done much more efficiently on a classical computer - for all we know, it's possible that tomorrow someone will come up with a novel algorithm that can break RSA in just a small number of operations. Same is true for elyptic curves - we don't have any mathematical proof that it's impossible for a much better algorithm than the currently known ones is possible.

However, just like for RSA we know that the problem of efficient integer factoring has been worked on for a long time with no progress, the same is true for quantum computing. We have been trying to figure out quantum algorithms for a great number of problems that are hard for classical computers for a long time now, and we haven't been able to, except for the ones that we have. Mathematicians have also developed certain intuitions for which problems have characteristics that make them potentially easier to solve on a QC and which don't.

In general, just like with P=NP?, we haven't proven yet if BQP, roughly the class of problems which have efficient QC versions, is equal or not to P, the class of problems that can be efficiently solved on a classical computer; and we also don't know if BQP=NP.

So yes, there is at least a theoretical possibility that the problems used for creating post-quantum encryption will turn out to be in BQP, will turn out to have an efficient quantum algorithm that solves them. But that would come from mathematical research, it is entirely unrelated to creating and tinkering with actual quantum computers. The math of quantum algorithms is currently far ahead of the engineering and physics on building the actual computers.

To answer your "if it's possible at all" question: it's full of hard engineering problems, but none of it looks unsolvable, and the investments are there.

And even if there was only a 10% chance of QC breaking crypto, the community is not comfortable with a 10% chance of such a catastrophic scenario.

This is part of my day job, so here's another interesting fact: for migrating encryption use cases, you have to consider that attackers can capture your encrypted data today to break in the future. So, as a rule of thumb, your migration timeline is much shorter for encryption than for signatures.

Well similar to how turing machines are a sufficient theoretical model to make all kinds of arguments about runtime complexity of classical computers without relying on their actual physical implementation, we have theoretical models for the way we are approaching quantum computation that do the same thing (Namely the quantum circuit model)

The problem is perhaps more theoretical than you might think. The security of post-quantum schemes basically comes down to the fact that researchers have thought long and hard about whether there are efficient classical or quantum algorithms to solve a given problem, and haven't found any yet. That's not necessarily anything new. Even RSA is predicated on no one having a fast factorisation algorithm.

I guess how technology and policy paths are layed out? It is basically a wish list. Like we already have the spec for 7G mobile comms decades ahead …(https://www.techsciresearch.com/blog/5g-vs-6g-vs-7g-unveilin... )

It's essentially the laws of physics. To oversimplify, Quantum computing can essentially do certain kinds of operations extremely fast (like factoring prime numbers) because it can calculate all the permutations almost instantly. But if you add intentional complexity to it in ways that all those states can't be "seen" then the quantum computer falls flat. That's one of the issues with adding post-quantum algorithms, they're by design less efficient in certain ways, meaning slower and/or with more overhead.

The way a quantum mechanics PhD explained it to me years ago in layman's terms is similar to nuclear science. We "knew" that a nuclear explosion was possible before a bomb was created and what conditions it would work. The Nagasaki bomb was a completely different type of bomb than the trinity test and Hirosima, plutonium instead of uranium, and it was never even tested before it's first use!

These are/will be the fundamentals of quantum logic.

https://en.wikipedia.org/wiki/Quantum_logic_gate

Bruce Schneier's books explain that there is far more to security than better encryption. Most are implemented incorrectly or used incorrectly.