Better encryption sounds good to me in general, but I don't really understand, how we can make quantum safe encryption, when we don't know yet, what capabilities it will have (or if it is possible at all).
I am obviously not in the field, but as far as I know, no QC is close of working for a practical purpose(aside quantum research), but to make it practical, it needs a groundbraking brakethrough of some sort. But if a brakethrough happens, can we really estimate the consequences?
Interesting development. Merkle Tree Certificates throw away decades of cruft, but also decades of battle testing and ancillary tools. I trust the teams involved, but this will be a hell of a project.
Still better than the alternatives that would saddle us with worse performance for ~ever.
> In the common case, the entire authentication path in an MTC handshake is one signature, one public key, and one inclusion proof. That’s smaller than today’s Web PKI handshake, even though MTCs use post-quantum algorithms. [...] There is more to MTCs than size optimization. Because every certificate is part of a published Merkle tree, transparency becomes a property of issuance itself. Today’s Certificate Transparency ecosystem is bolted on after the fact: certificates are issued by CAs, then logged separately, with extra signatures riding along in the TLS handshake to attest to that logging. With MTCs, a certificate cannot exist outside the Merkle tree. Certificate Transparency is built in.
These upsides seem extremely promising, but I'm curious to know if there are any notable downsides as well.
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.
We are truly living in a science fiction future where quantum code cracking is not a remote possibility but a near term risk we are planning for.
In Vernor Vinge's novel "A Fire Upon the Deep" one of the most valuable commodities were one time pads that are physically transported to communication nodes to enable unbreakable communication. The pads are split into three pieces that are XORed to create the actual pad to reduce risk of compromise.
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.
nsa and eu pushing for replacement of the reliable algorithms with unproven and very likely backdoored post-quantum algorithms, when there is no real threat at all, is highly suspicious.
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).
> all the post-quantum algorithms implemented by OpenSSH are "hybrids" that combine a post-quantum algorithm with a classical algorithm. For example mlkem768x25519-sha256 combines ML-KEM, a post-quantum key agreement scheme, with ECDH/x25519, a classical key agreement algorithm that was formerly OpenSSH's preferred default. This ensures that the combined, hybrid algorithm is no worse than the previous best classical algorithm, even if the post-quantum algorithm turns out to be completely broken by future cryptanalysis.
I've been working on a new project using ed25519 signatures and discovered they are not quantum resistant.... I went with ed25519 due to possibility of using openssh keys. Any opinion on this choice at the light of this article and other quantum computing news?
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.
the rational argument is that this time is not particularly worse than prior transitions, and arguably is one we are doing much more clear-eyed (think about all the ECC vulnerabilities during their first few years of deployment due to not knowing how to "pick safe curves". The analogous issue for standardized NIST PQ schemes is understood very well). So the hysteria around the transition, from an expert's perspective, is misplaced.
This doesn't guarantee things will work. In cryptography there are no guarantees. In particular, failing to transition fast enough can also lead to vulnerabilities (by this I mean quantum attacks. Cryptographers are increasingly worried this may happen very soon. I've seen some estimate as soon as 2030). So there is an underlying tension in changing, and also a clear worry about not changing.
This post completely fails to address one of my biggest fears with a batched approach: waiting for a brand new certificate to be provisioned for a server that does not already have one. If batches are executed too frequently, then clients will have too big a database to maintain. If batches are executed too infrequently, then I have to wait a while to get my first certificate. Are they doing anything about this or is this just how it'll be with these new quantum-resistant certificates?
Nation states have been pouring billions into QC. It's hard to collect the varous announcements into clean figures, but rough estimates are that the US has allocated ~$5B to QC computation research, the EU (via the EU itself, and individual member states) have allocated more (closer to ~$10B-15B), and China has allocated a similar amount (again in the ~$10B range).
Industry quantum computing has made precipitous progress in the last few years, leading to industry companies (e.g. Cloudflare) to upping their personal targets for transition to 2029. You can read their motivation in the first few paragraphs of the following
We are currently in a place where it is entirely plausible that nation states will have quantum computers capable of breaking EC crypto (and RSA, although paradoxically it is mildly harder to break quantumly due to larger data sizes) by 2030. This is not guaranteed. But there have been increasingly many warning signs.
Maybe you don't care, and want to bury your head in the sand. That's your prerogative. But cryptographers do care, and so are taking all of the above very seriously.
From the article not everything is fully clear to me yet.
What I do think though, is that Certificate Transparency as we currently have it is a fairly broken mess. Maybe partly due to RFC 6962.
The easiest task might just be validating SCTs. Easy, you just validate a signature... But no, that doesn't yet prove that the cert has been logged, that requires doing an inclusion proof!
So, someone can do inclusion and consistency proofs. If a log presents a split view that should be noticable through gossiping. But what gossiping is implemented? I think the only gossiping that happens is in the CT Google group/mailing list that probably few people know of.
Then, what if you want to actually detect malicious or misissued certs for your domain? Ideally you want to do it yourself and not use some service. Probably you just have one server and IP. Now you have to download insane amounts of data from ~60 logs and hope that someone else is checking the consistency and correctness of those logs. And you have to scrape those logs faster than they grow. Now, what if everyone running a web server did monitor? Even static logs probably couldn't withstand that.
Next, what about the log lists? One can talk all about sovereignty but really you rely on and have to trust Apple and Google with their policies and log lists if you want to meaningfully participate in this system and by extension, the encrypted web...
CT is fully deployed to production but still has many design flaws and things that are still just theoretical. It seems many of them are addressed by MTCs. I hope it can be better.
The one thing I didn't see addressed is the gossiping thing. Couldn't a malicious CA still present a split view under this model?
And if I'll have to rely on mirrors then I still can't independently monitor.
in-case core-devs from LE lurk here: check out Cordon, a draft-ietf-plants-merkle-tree-certs-03 compliant CA and ACME server. its being used in a private mixnet now.
So what's the timeline for a quantum future? 20 years? 50 years? 100? My concern is that it's primarily a materials science problem (hence, it is going to take a very long time).
27 comments
[ 2.9 ms ] story [ 55.6 ms ] threadI am obviously not in the field, but as far as I know, no QC is close of working for a practical purpose(aside quantum research), but to make it practical, it needs a groundbraking brakethrough of some sort. But if a brakethrough happens, can we really estimate the consequences?
Still better than the alternatives that would saddle us with worse performance for ~ever.
These upsides seem extremely promising, but I'm curious to know if there are any notable downsides as well.
> 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!
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.
In Vernor Vinge's novel "A Fire Upon the Deep" one of the most valuable commodities were one time pads that are physically transported to communication nodes to enable unbreakable communication. The pads are split into three pieces that are XORed to create the actual pad to reduce risk of compromise.
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.
Almost. Quantum is neither a remote risk nor a near-term possibility. Woof, woof, woof! https://eprint.iacr.org/2025/1237
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).
> all the post-quantum algorithms implemented by OpenSSH are "hybrids" that combine a post-quantum algorithm with a classical algorithm. For example mlkem768x25519-sha256 combines ML-KEM, a post-quantum key agreement scheme, with ECDH/x25519, a classical key agreement algorithm that was formerly OpenSSH's preferred default. This ensures that the combined, hybrid algorithm is no worse than the previous best classical algorithm, even if the post-quantum algorithm turns out to be completely broken by future cryptanalysis.
I wrote this in April. Many folks' misconceptions about post-quantum cryptography and "hybrid" constructions are answerable with this blog post.
This doesn't guarantee things will work. In cryptography there are no guarantees. In particular, failing to transition fast enough can also lead to vulnerabilities (by this I mean quantum attacks. Cryptographers are increasingly worried this may happen very soon. I've seen some estimate as soon as 2030). So there is an underlying tension in changing, and also a clear worry about not changing.
Industry quantum computing has made precipitous progress in the last few years, leading to industry companies (e.g. Cloudflare) to upping their personal targets for transition to 2029. You can read their motivation in the first few paragraphs of the following
https://blog.cloudflare.com/post-quantum-roadmap/
We are currently in a place where it is entirely plausible that nation states will have quantum computers capable of breaking EC crypto (and RSA, although paradoxically it is mildly harder to break quantumly due to larger data sizes) by 2030. This is not guaranteed. But there have been increasingly many warning signs.
Maybe you don't care, and want to bury your head in the sand. That's your prerogative. But cryptographers do care, and so are taking all of the above very seriously.
the quantum industry in reality: "Using Shor’s algorithm, the largest integer factored into primes is 15" :)))
What I do think though, is that Certificate Transparency as we currently have it is a fairly broken mess. Maybe partly due to RFC 6962.
The easiest task might just be validating SCTs. Easy, you just validate a signature... But no, that doesn't yet prove that the cert has been logged, that requires doing an inclusion proof!
So, someone can do inclusion and consistency proofs. If a log presents a split view that should be noticable through gossiping. But what gossiping is implemented? I think the only gossiping that happens is in the CT Google group/mailing list that probably few people know of.
Then, what if you want to actually detect malicious or misissued certs for your domain? Ideally you want to do it yourself and not use some service. Probably you just have one server and IP. Now you have to download insane amounts of data from ~60 logs and hope that someone else is checking the consistency and correctness of those logs. And you have to scrape those logs faster than they grow. Now, what if everyone running a web server did monitor? Even static logs probably couldn't withstand that.
Next, what about the log lists? One can talk all about sovereignty but really you rely on and have to trust Apple and Google with their policies and log lists if you want to meaningfully participate in this system and by extension, the encrypted web...
CT is fully deployed to production but still has many design flaws and things that are still just theoretical. It seems many of them are addressed by MTCs. I hope it can be better.
The one thing I didn't see addressed is the gossiping thing. Couldn't a malicious CA still present a split view under this model?
And if I'll have to rely on mirrors then I still can't independently monitor.
bonus points: its AOT compiled dotnet
https://github.com/maceip/cordon