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!
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."
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).
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.
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.
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.
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.
No worries, thanks for sharing that post anyway! Another post of yours[1] turned out to be a useful resource for me not too long ago, and the artwork is pretty entertaining.
Hi, just a personal blog post. The sad story of Gandi.net is a textbook example of enshittification, which I think is interesting to talk about, because of the many expectations that were betrayed, and the deeper reflection linking to vampire capitalism. I also report the user-hostile process that I had to undergo in order to migrate away from them.
Author of the whine post here, feedback is very welcome. I am in no way expert on the topic of AI/LLM, and I'm happy to learn new things and correct myself. My point on the "China has won the AI race", while admittedly provocative, is not meant in the technological sense, but in a broader, social + usability sense: I know that there are good open source models by Western companies, I know Heretic and similar abliteration techniques, and yet all the trending models on HF are Qwen and friends, and sovereign and/or private attempts at personal inference like Euria, Confer, etc use these models under the hood. While you might or not be right that "there is no Chinese company that can release a model as good as the American ones" (and BTW, this statement sounds difficult to prove to me), how do you explain the observable, objective facts above? Thanks.
Hi, I wanted to share this because at first I found it super ridiculous that a "green, open and ethical Switzerland-hosted AI" spews so obvious CCP propaganda like that, but then I realized the issue runs deeper. I always see a lot of interesting conversations on HN about AI, so I guess a starting question I would like to ask you is: what is, today, the "best" general-purpose open-source model one can self-host on expensive but consumer-grade hardware? Thanks!
I’m looking at the site and right at the beginning it says:
> Standard.site provides shared lexicons for long-form publishing on AT Protocol. Making content easier to discover, index, and move across the ATmosphere.
Which part of these required a new protocol and couldn’t be built before @at existed? Seems to me we’re reinventing the wheel for I’m not entirely sure which benefit. But maybe someone who’s more into this part of the web can educate me on this.
> Which part of these required a new protocol and couldn’t be built before @at existed? Seems to me we’re reinventing the wheel for I’m not entirely sure which benefit.
The atproto folks went and categorized all of the other attempts to do this at the time. (They even had some I hadn't heard of!)
All of them make various tradeoffs. None of them were the set of tradeoffs the team wanted. So they needed to make some new things. That's really the core of it.
My sibling has one of the largest and most specific things, but this is the underlying reason.
Did that require an entire new protocol though? I am 100% sure that if Twitter, Facebook and all the other platforms decided that they want to offer a way to move around accounts they could do it.
The protocol is much more than data portability, it essentially turns the global social media system into a giant distributed system anyone can participate in at any point. Imagine if FB also let you tap into the event stream or produce your own event stream other FB users could listen to in the official FB app. That would be a pretty awesome requirement for all social media apps, yea?
I am not debating that. But this same reasoning applies to @at or any other implementation. You have to be willing to implement the features and use the protocol. So I still don’t see why this is any different.
Forgive me this shameless ad :) with the latest performance updates, Shufflecake ( https://shufflecake.net/ ) is blazing fast (so much, in fact, that exceeds performances of LUKS/dm-crypt/VeraCrypt in many scenarios, including SSD use.
I see a lot of comments recommending TrueCrypt/VeraCrypt here, which is fine, but did you know there is something even more interesting? ;)
Shufflecake ( https://shufflecake.net/ ) is a "spiritual successor" to TrueCrypt/VeraCrypt but vastly improved: works at the block device level, supports any filesystem of choice, can manage many nested layers of secrecy concurrently in read/write, comes with a formal proof of security, and is blazing fast (so much, in fact, that exceeds performances of LUKS/dm-crypt/VeraCrypt in many scenarios, including SSD use).
Disclaimer: it is still a proof of concept, only runs on Linux, has no security audit yet. But there is a prototype for the "Holy Grail" of plausible deniability on the near future roadmap: a fully hidden Linux OS (boots a different Linux distro or Qubes container set depending on the password inserted at boot). Stay tuned!
It is scary! my coping mechanism, which I admit is stupid, is to believe no matter what I do as long as I am online they have my data. But you are right most people just give absurd amount of data for willingly.
And the surveillance could be inversely correlated to profitability. If they pour billions into these chat bots and can't monetize them to the revolutionary oracles they touted, one minor consolation is to sell detailed profiles about the people using them. You could probably sort out the less intelligent people based on what they were asking.
> 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!
reply