I'm actually quite surprised that anyone is advocating the non-hybrid PQ key exchange for real applications. If it isn't some sort of gimmick to allow NSA to break these, it's sure showing a huge amount of confidence in relatively recently developed mechanisms.
It feels kind of like saying "oh, now that we can detect viruses in sewage, hospitals should stop bothering to report possible epidemic outbreaks, because that's redundant with the sewage monitoring capability". (Except worse, because it involves some people who may secretly be pursuing goals that are the opposite of everyone else's.)
Edit: DJB said in that 2022 post
> Publicly, NSA justifies this by
>
> . pointing to a fringe case where a careless effort to add an extra security layer damaged security, and
> . expressing "confidence in the NIST PQC process".
There is so much here to debate about. A) Never trust the cyber feds. B) The NSA is not the place anyone thinks, it’s a Wild West in the most bizarre of places, trust me from experience. C) Cryptology concerns more of than security and exchanging messages or packets, sometimes you don’t even know what kind of thing (living) can and has been decrypted. D) The NSA plays very, very, very dirty. It is like a digital CIA, they are in everything (i.e. cyber spies in various roles at tech/telecom/manufacturer company xyz). E) NEVER LISTEN TO THE DAMN NSA / DRIVEN BY A CULTURE OF EXPLOITATION
This is quite concerning, and respect to DJB for fighting against it. However, I have to wonder...who would this actually compromise that matters to NSA?
* Targets with sufficient technical understanding would use hybrids anyway.
* Average users and unsophisticated targets can already be monitored through PRISM which makes cryptography moot.
It is concerning that the IETF is moving forward with a proposal that weakens security and is of questionable technical merit, with the most reasonable explanation being that this is the result of efforts by government surveillance agencies to enable or potentially enable monitoring of encrypted communications supposedly protected by this standard; additionally, it is concerning that disagreeing with this decision is being met with censure and outright hostility by leaders of the IETF.
I think the point is... even if you can't get everyone to adopt your backdoored technology, you are much better off if 30% of the market adopts it than if >1%...
Intelligence is a numbers game, they never get everything, but if your net is wide enough and you don't give up, you'll catch a lot of fish over time
Lots of respect to both you and the author, but the rejection gives no real response to any of the issues I see raised in the document.
It failed to raise my confidence at all.
> The IESG has concluded that there were no process failures by the SEC ADs. The IESG declines to directly address the complaint on the TLS WG document adoption matter. Instead, the appellant should refile their complaint with the SEC ADs in a manner which conforms to specified process.
It's still nice that it was put up for completeness. And as we know this stuff has a long sordid history of people who are proponents of weakening encryption not giving up easily.
I used to be such a fan of this guy. But he's turned into Ed Zitron, the same long rambling rants, except about cryptography, and except that he knows what he's talking about, and he knows that you have to know literally nothing at all about the field he's commenting on to associated Dual EC with anything happening in PQ. And if you know anything about the field, trying to compare MLKEM with SIKE is the same deal. It's really sad.
Dual EC wasn't a shockingly clever, CS-boundary-pushing hack (and NSA has apparently deployed at least one of those in the last 20 years). It was an RNG (not a key agreement protocol) based on asymmetric public key cryptography, a system where you could look at it and just ask "where's the private key?" There wasn't a ton of academic research trying to pick apart flaws in Dual EC because why would there be? Who would ever use it?
(It turns out: a big chunk of the industry, which all ran on ultra-closed source code and was much less cryptographically literate that most people thought. I was loudly wrong about this at the time!)
MLKEM is a standard realization of CRYSTALS-Kyber, an algorithm submitted to the NIST PQ contest by a team of some of the biggest names in academic PQ cryptography, including Peter Schwabe, a prior collaborator of Bernstein. Nobody is looking at MLKEM and wondering "huh, where's the private key?".
MLKEM is based on cryptographic ideas that go back to the 1990s, and were intensively studied in the 2000s. It's not oddball weird cryptography. It is to the lineage of lattice cryptography roughly what Ed25519 was to elliptic curve cryptography at the time of Ed25519's adoption.
Utterly unlike SIKE, which isn't a lattice algorithm at all, but rather a supersingular isogeny algorithm, a cryptographic primitive based on an entirely new problem class, and an extremely abstruse one at that. The field had been studying lattice cryptography intensively for decades by the time MLKEM came to pass. That's not remotely true of isogeny cryptography. Isogenies were taken seriously not because of confidence in the hardness of isogenies, but because of ergonomics: they were a drop-in replacement for Diffie Hellman in a way MLKEM isn't.
These are all things Bernstein is counting on you not knowing when you read this piece.
For the same reason your Toyota Camry doesn't have a roll cage.
I'd use a hybrid if I was designing a system; I am deeply suspicious of all cryptography, and while I don't think Kyber is going to collapse, I wouldn't bet against 10-15 years of periodic new implementation bugs nobody knew to look for.
But I'm cynical about cryptography. It's really clear why people would want a non-hybrid code point.
Let me just say this once as clearly as I can: I sort of don't give a shit about any of this. A pox on all their houses. I think official cryptographic standards are a force for evil. More good is going to be done for the world by systems that implement well enough to become de facto standards. More WireGuards, fewer RFCs. Certainly, I can't possibly give even a millifuck about what NIST wants.
But I also can't be chill about these blog posts Bernstein writes where it's super clear his audience is not his colleagues in cryptography research, but rather a lay audience that just assumes anything he writes must be true and important. It's gross, because you can see the wires he's using to hold these arguments together (yes, even I can see them), and I don't like it when people insult their audiences this way.
It's really clear why people would want a non-hybrid code point.
To me it really isn't. TLS has no need for it. But let's focus the context for some US government organisations that want this for their FIPS maturity level they're aiming for. Why would these organisations want a weaker algorithm for TLS than what is standardised; more importantly how does it benefit deployment except save a tiny bit of computation and eliminate some ECC code. I'm not going to jump the shark and say it is nefarious, but I will throw in my 2 cents and say it doesn't help security and is unnecessary.
> For the same reason your Toyota Camry doesn't have a roll cage.
It does though. It's just been engineered integral to the unibody. And there are crumple zones, airbags, seat belts, ABS, emergency braking systems, collision sensors, and more layered defenses in addition.
No sane engineer would argue that removing these layers of defense would make the car safer.
DJB has been complaining about this NSA position since 2022 (I guess long before it was an issue at the TLS WG):
https://blog.cr.yp.to/20220805-nsa.html
I'm actually quite surprised that anyone is advocating the non-hybrid PQ key exchange for real applications. If it isn't some sort of gimmick to allow NSA to break these, it's sure showing a huge amount of confidence in relatively recently developed mechanisms.
It feels kind of like saying "oh, now that we can detect viruses in sewage, hospitals should stop bothering to report possible epidemic outbreaks, because that's redundant with the sewage monitoring capability". (Except worse, because it involves some people who may secretly be pursuing goals that are the opposite of everyone else's.)
Edit: DJB said in that 2022 post
Expand on "recently-developed mechanisms".
There is so much here to debate about. A) Never trust the cyber feds. B) The NSA is not the place anyone thinks, it’s a Wild West in the most bizarre of places, trust me from experience. C) Cryptology concerns more of than security and exchanging messages or packets, sometimes you don’t even know what kind of thing (living) can and has been decrypted. D) The NSA plays very, very, very dirty. It is like a digital CIA, they are in everything (i.e. cyber spies in various roles at tech/telecom/manufacturer company xyz). E) NEVER LISTEN TO THE DAMN NSA / DRIVEN BY A CULTURE OF EXPLOITATION
The mere idea that that they want to do this makes me want a 3rd layer of encryption on top of the other 2.
This is quite concerning, and respect to DJB for fighting against it. However, I have to wonder...who would this actually compromise that matters to NSA?
* Targets with sufficient technical understanding would use hybrids anyway.
* Average users and unsophisticated targets can already be monitored through PRISM which makes cryptography moot.
So...what's their actual end game here?
Coupled with QUANTUMINSERT, it would enable a https://en.wikipedia.org/wiki/Downgrade_attack even for folks who might otherwise be using stronger encryption methods.
What's quite concerning? Be specific.
It is concerning that the IETF is moving forward with a proposal that weakens security and is of questionable technical merit, with the most reasonable explanation being that this is the result of efforts by government surveillance agencies to enable or potentially enable monitoring of encrypted communications supposedly protected by this standard; additionally, it is concerning that disagreeing with this decision is being met with censure and outright hostility by leaders of the IETF.
I'm asking how, specifically, it "weakens security" and is of "questionable technical merits". The IETF isn't a government body.
I think the point is... even if you can't get everyone to adopt your backdoored technology, you are much better off if 30% of the market adopts it than if >1%...
Intelligence is a numbers game, they never get everything, but if your net is wide enough and you don't give up, you'll catch a lot of fish over time
It's a touch odd to make a big deal of the fact that you've filed a complaint and fail to mention that it was formally rejected three days before you published the post: https://datatracker.ietf.org/group/iesg/appeals/artifact/146
Lots of respect to both you and the author, but the rejection gives no real response to any of the issues I see raised in the document.
It failed to raise my confidence at all.
> The IESG has concluded that there were no process failures by the SEC ADs. The IESG declines to directly address the complaint on the TLS WG document adoption matter. Instead, the appellant should refile their complaint with the SEC ADs in a manner which conforms to specified process.
I feel like if your argument is that the rules weren't followed, you have a pretty strong obligation to follow the rules in submitting your complaint.
Having served on boards, rejections on procedural grounds which fail to address engineering concerns which have been raised stink of a cop-out.
Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly.
> Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly.
This complaint? https://cr.yp.to/2025/20250812-non-hybrid.pdf
Engineering concerns start in section 2 and continue through section 4.
It seems you haven't read it.
It's still nice that it was put up for completeness. And as we know this stuff has a long sordid history of people who are proponents of weakening encryption not giving up easily.
Ah FIPS, the bastion of security standards.
I used to be such a fan of this guy. But he's turned into Ed Zitron, the same long rambling rants, except about cryptography, and except that he knows what he's talking about, and he knows that you have to know literally nothing at all about the field he's commenting on to associated Dual EC with anything happening in PQ. And if you know anything about the field, trying to compare MLKEM with SIKE is the same deal. It's really sad.
Dual EC wasn't a shockingly clever, CS-boundary-pushing hack (and NSA has apparently deployed at least one of those in the last 20 years). It was an RNG (not a key agreement protocol) based on asymmetric public key cryptography, a system where you could look at it and just ask "where's the private key?" There wasn't a ton of academic research trying to pick apart flaws in Dual EC because why would there be? Who would ever use it?
(It turns out: a big chunk of the industry, which all ran on ultra-closed source code and was much less cryptographically literate that most people thought. I was loudly wrong about this at the time!)
MLKEM is a standard realization of CRYSTALS-Kyber, an algorithm submitted to the NIST PQ contest by a team of some of the biggest names in academic PQ cryptography, including Peter Schwabe, a prior collaborator of Bernstein. Nobody is looking at MLKEM and wondering "huh, where's the private key?".
MLKEM is based on cryptographic ideas that go back to the 1990s, and were intensively studied in the 2000s. It's not oddball weird cryptography. It is to the lineage of lattice cryptography roughly what Ed25519 was to elliptic curve cryptography at the time of Ed25519's adoption.
Utterly unlike SIKE, which isn't a lattice algorithm at all, but rather a supersingular isogeny algorithm, a cryptographic primitive based on an entirely new problem class, and an extremely abstruse one at that. The field had been studying lattice cryptography intensively for decades by the time MLKEM came to pass. That's not remotely true of isogeny cryptography. Isogenies were taken seriously not because of confidence in the hardness of isogenies, but because of ergonomics: they were a drop-in replacement for Diffie Hellman in a way MLKEM isn't.
These are all things Bernstein is counting on you not knowing when you read this piece.
To use his analogy though, why remove seatbelts? It's like saying we have IPv6 now, why do we need IPv4 support.
For the same reason your Toyota Camry doesn't have a roll cage.
I'd use a hybrid if I was designing a system; I am deeply suspicious of all cryptography, and while I don't think Kyber is going to collapse, I wouldn't bet against 10-15 years of periodic new implementation bugs nobody knew to look for.
But I'm cynical about cryptography. It's really clear why people would want a non-hybrid code point.
Let me just say this once as clearly as I can: I sort of don't give a shit about any of this. A pox on all their houses. I think official cryptographic standards are a force for evil. More good is going to be done for the world by systems that implement well enough to become de facto standards. More WireGuards, fewer RFCs. Certainly, I can't possibly give even a millifuck about what NIST wants.
But I also can't be chill about these blog posts Bernstein writes where it's super clear his audience is not his colleagues in cryptography research, but rather a lay audience that just assumes anything he writes must be true and important. It's gross, because you can see the wires he's using to hold these arguments together (yes, even I can see them), and I don't like it when people insult their audiences this way.
It's really clear why people would want a non-hybrid code point.
To me it really isn't. TLS has no need for it. But let's focus the context for some US government organisations that want this for their FIPS maturity level they're aiming for. Why would these organisations want a weaker algorithm for TLS than what is standardised; more importantly how does it benefit deployment except save a tiny bit of computation and eliminate some ECC code. I'm not going to jump the shark and say it is nefarious, but I will throw in my 2 cents and say it doesn't help security and is unnecessary.
[delayed]
> For the same reason your Toyota Camry doesn't have a roll cage.
It does though. It's just been engineered integral to the unibody. And there are crumple zones, airbags, seat belts, ABS, emergency braking systems, collision sensors, and more layered defenses in addition.
No sane engineer would argue that removing these layers of defense would make the car safer.