[tomgag]

Refreshing! Not wanting to be the "told you so" guy, I've been saying this for at least 2 years now:

> Post-quantum authentication is no longer a problem the Web PKI ecosystem should defer. Long-lived keys (root certificate authorities, code-signing keys, identity systems) are particularly valuable targets, and new technology takes years to gain broad adoption, so the work has to start early.

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.

There are two problems here.

The first one is included by the Letsencrypt announcement: the migration path for signatures/certificates is typically longer and more complex than encryption: long-lived certificates, firmware update keys, secure boot certificates, these are all objects that are painful to migrate.

The second one, even more serious in my opinion, is: "retroactive" in respect to what? "Retroactive" presupposes you can observe the trigger (the arrival of a cryptanalytically-relevant quantum computer), but this is precisely the kind of capability an adversary keeps secret, and a quantum forgery is operationally indistinguishable from, e.g., key exfiltration, a library bug, or a classical break. You may see a forged signature, a drained wallet, a failing certificate, and have no way to attribute it to quantum cryptanalysis. The threat is dark: reactive migration against an unobservable trigger is structurally impossible.

This is not to say that Harvest-Now-Decrypt-Later is a less urgent threat, but it's not so asymmetric as people have been believing so far. Glad to see things are changing!

[thyristan]

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.

[some_furry]

> 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."

[tomgag]

Yes, totally agreed, but the problem is that most people tend to simplify this as "let's just bother with PQ encryption, forget about signatures". I know experts can handle the nuance, but execs and most industry folks can't. Or, at least, this is the trend that I have personally observed countless times, maybe I was just unlucky with my data points, but I have seen this in "technical" settings as well (case in point: GnuPG prioritized inclusion of PQ hybrid encryption, to the point of rushing the standard against OpenPGP, the well-known "GnuPG schism", but I'm not aware of concrete plans for PQ signature adoptions there).

[buu700]

I agree. If we're going the rally the industry to do the work, it should be the whole work in one shot. Any given project/infrastructure that implements both encryption and signing should adopt ML-DSA/SLH-DSA at the same time as ML-KEM, or at least in immediate succession.

My concern is that PQC is having a bit of a Y2K moment, and undercapitalizing on that sense of urgency may risk letting PQ signatures drag on for ages like IPv6. "We need $X engineering budget for PQC" is easy to understand, but "we need $X for PQ encryption now and $Y for PQ signing at some undefined future time" is murkier and may require getting into the weeds on cryptographic concepts and speculative CRQC timelines with non-expert stakeholders.

[some_furry]

> signing should adopt ML-DSA/SLH-DSA at the same time as ML-KEM

I know you mean well, but this proposal maximizes the downsides of PQ signatures.

Both ML-DSA and SLH-DSA have enormous keys. SLH-DSA is also very slow, while ML-DSA is relatively fast: https://blog.cloudflare.com/another-look-at-pq-signatures/

One of the biggest challenges with the signatures currently standardized is the signature + public key sizes. Demanding we hybridize both just maximizes the pain, and there's no real incentive for this.

As I wrote in https://soatok.blog/2026/04/13/hybrid-constructions-the-post..., the justification for composite/hybrid signatures just isn't there.

Use ML-DSA-44. Don't combine it with other crap. It's good enough.

For KEMs, X-Wing (mlkem768x25519) is great, but ML-KEM-768 and ML-KEM-1024 are also fine on their own. Hybrids are the path of least resistance here, so I prefer them, but have no concerns over ML-KEM's security.

[buu700]

I wasn't implying that the two should be hybridized. I think both are great options to have in our toolkit. For example, in Cyph I chose ML-DSA for end user signing keys + certificates and SLH-DSA for code signing.

[some_furry]

Sorry, I did entirely misread your words.