[tptacek]

The two most important things to understand about this kerfuffle:

(1) MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe; their submission, Kyber, was selected in an open competition in which Bernstein himself submitted a closely-related algorithm (and then contested the result, suing NIST for documents to clarify the selection.)

(2) The RFC at issue documents the possibility of running TLS with pure MLKEM rather than in a hybrid configuration with ECDH. Hybrid TLS is already the mainstream, documented, standardized method for using PQC in a TLS connection. Bernstein is canvassing opposition to any documentation of the possibility of pure MLKEM in TLS.

Every time Bernstein talks about NSA's sordid history, remember: nothing that's happening here has really anything to do with NSA. It would make more sense for Bernstein to be canvassing against SHA2, which NSA actually did design. But he can't do that, because normal people know enough about cryptography to understand how crazy a claim that is. Unfortunately, we can't yet say that about lattice cryptography, despite it being approximately as well-studied as ECC.

[ekr____]

> (2) The RFC at issue documents the possibility of running TLS with pure MLKEM rather than in a hybrid configuration with ECDH. Hybrid TLS is already the mainstream, documented, standardized method for using PQC in a TLS connection. Bernstein is canvassing opposition to any documentation of the possibility of pure MLKEM in TLS.

Two more pieces of context here: 1. The IETF allows code point registrations based purely on the existence of a specification, and the pure ML-KEM code points have already been assigned (https://www.iana.org/assignments/tls-parameters/tls-paramete...). The question at hand is whether the IETF will publish an RFC documenting the ML-KEM cipher suites [edited to make clear that ML-KEM is documented already].

2. It is also possible to publish an RFC via what's called "Independent Submission" (https://www.rfc-editor.org/authors/rfc-independent-submissio...), which is not subject to the IETF Consensus process. This is, for instance, how the GOST RFC (https://datatracker.ietf.org/doc/rfc9367/) was published. If the IETF opts not to publish this draft, the authors can still submit it to the Independent Submissions Editor.

[throw0101d]

> https://www.iana.org/assignments/tls-parameters/tls-paramete...

Further the draft that this is all about does not make a recommendation for its use. The currently IETF-recommended TLS algorithms are: X25519MLKEM768, x448, x25519, secp384r1, secp256r1.

As noted by someone on the IETF list [1] there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document. No one is forcing anyone to use this algorithm, and it's not even 'officially' recommended (per above).

[1] https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...

[g-b-r]

If it's supported it will be used, e.g. by vendors which decide for some reason to use it

Null encryption used to be supported as well, and no one was forced to use it.

But when something insecure is supported by a protocol it will lead to security hiccups.

If it's dangerous it shouldn't be supported.

[lokar]

But that’s not what the IETF is. They don’t police, they encourage collaboration and standardization between implementers.

[ButlerianJihad]

Heh heh heh.

I recall the early-to-mid-90s when the IETF was a powerhouse, churning out foundational standards and documents monthly, and every time I read a foundational RFC for some protocol I wanted to learn, the "Security Considerations" section was intentionally left completely blank and un-considered.

I don't know if it was recklessness or expediency or a very calculated tactic (the Internet was invented by DARPA, after all) but Internet protocols were so ridiculously insecure, and based on absurd trust models that were repeatedly broken, and everything always transmitted in plaintext (because, of course, all networks were physically wired, secured, and only the good guys could tap into them).

It was an absolute Wild West clown college as the Internet transitioned to commercial and privatized use cases, and I suppose it guaranteed job security for generations of cybersecurity experts and cryptographers.

[leonidasrup]

In the 90s, you as a private person were not supposed to have access to encyption which could not be broken by NSA.

"The longest key size allowed for export without individual license proceedings was 40 bits, so Netscape developed two versions of its web browser. The "U.S. edition" had the full 128-bit strength. The "International Edition" had its effective key length reduced to 40 bits by revealing 88 bits of the key in the SSL protocol."

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

[g-b-r]

They publish what become standards, you can't just support any existing option in an encryption protocol (if you want to have a secure one).

[AdamN]

The standardization process should weed out 'footguns' that are prone to accidentally (or maliciously) lowering the security bar.

[dhx]

To point out some positive examples of what RFCs should include:

RFC 5288 s3 (AES-GCM): "Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security."[1]

RFC 7748 s5 (X25519): "The cswap function SHOULD be implemented in constant time (i.e., independent of the swap argument)."[2]

By contrast, this proposed RFC for MLKEM provides a single encouragement:

"[NIST-SP-800-227] includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."[3]

It's not even a SHOULD, it's just an encouragement in a non-normative section of the RFC.

When you go to the referred NIST SP 800-227 it then tells you it's all too hard anyway and good luck and have fun figuring it out yourself:

"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."[4]

The normative standard FIPS 203[5] which the draft MLKEM RFC relies upon NEVER mentions "side channel", "constant", "timing" or provides any other assistance to implementers on how to securely multiply and/or divide numbers on computers or how to deal with conditional branching. Fair enough it includes a lower case "should" for considering side-channel resistance, but this throwaway comment is inadequate for standardisation.

The main reason it is inadequate is, imagine you're on your Hardened Gentoo or some other uber-geek laptop with the most advanced and thoroughly tested side channel resistant MLKEM client imaginable. You want to access your bank's website that offers MLKEM-only TLS. You don't have any assurance the bank's implementation of MLKEM has implemented any side channel resistance because the RFC they claim to have implemented never required it. If you then extrapolate from historical woes of implementing side channel resistant crypto (ECDSA scalar multiplication for example), it's probably correct to assume someone has, or reasonably could at some point in the future, extract private keys from the bank's side, and thus your expectations of having a secure connection are unmet. This is a standardisation problem because two implementations cannot agree on whether the protocol offers any resistance to side channel leakage to remote adversaries, therefore, what is the security guarantee the two implementations can actually agree upon?

The key missing section of this RFC is perhaps a restriction on its application similar to:

"This standard does not require implementations to consider side-channel attacks. This standard SHOULD NOT be used for protecting data and communications where an adversary may have one or more of: a) physical access to equipment performing cryptographic operations and time and resources necessary to observe physical properties of the equipment (power and signal characteristics, electromagnetic radiation, thermal dissipation), b) ability to execute code on equipment performing cryptographic operations, c) remote access to high-resolution monitoring data of physical properties of equipment performing cryptographic operations, d) ability to observe and/or establish a session to a party using this cryptographic protocol."

Thus it'd only be applicable to low risk environments such as two servers in a government building in separate rooms where an adversary is prevented from conducting a side channel attack by a plethora of other security controls.

[1] https://datatracker.ietf.org/doc/html/rfc5288#section-3

[2] https://datatracker.ietf.org/doc/html/rfc7748#section-5

[3] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

[4] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[5] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

[mswphd]

using pure ML-KEM is not a footgun. Some people may have doubts about lattice-based cryptography, despite being securely deployed in Chrome nearly a decade ago. Some people have doubts about many things. The fact that people have doubts does not make the scheme a "footgun".

[chrismorgan]

> there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document

“People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t.

(There are counter-arguments as well, of course. A couple of relevant cases that spring to mind where a body has not aligned with usage or expectations: W3C lost control of HTML, and it was probably for the best, but they remain a relevant body in closely-related areas; and OSI licence approval is a horribly broken political process which is almost universally misunderstood and close to frozen in time, yet they haven’t suffered like they should have for their misdeeds, they pretty much got away with it. There was also that thing somewhat recently about FedRAMP rubber-stamping Microsoft Cloud despite it failing dismally, because US government agencies had already started using it too much; and I wonder what that does to their credibility.)

This is also a concern with informational/independent submissions through IETF. They are frequently perceived as having IETF/standards weight.

[tptacek]

These are arguments, but I don't really understand what they're arguments for. At issue here is whether or not the IETF should document usage of pure-MLKEM TLS. There are environments where people are going to use pure-MLKEM TLS, whether Bernstein likes it or not. His argument is that the IETF should pretend that isn't happening, and throw up weird procedural obstacles to it.

[chrismorgan]

I know approximately nothing about the specific case here, and don’t believe I have any skin in the game. I intended my comment purely abstractly: I’m not commenting on anything technical, merely mentioning a procedural concern: that the line I quoted can sound reasonable, but that I don’t think it’s actually a reasonable argument by itself, because of the likely consequences of such actions. (That is: if that happened to be the only argument—though I doubt it is—there’s a compelling case for rejecting it.)

[g-b-r]

If it's documented it will be implemented by many more libraries and applications, that's the argument

[tptacek]

It already exists. In fact, there are environments where it has to exist. So the argument he's making is that the IETF should pretend it doesn't exist.

[throw0101d]

> “People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t.

The GOST cipher, which is Russia's AES equivalent, is also in an RFC:

* https://datatracker.ietf.org/doc/html/rfc9189

* https://en.wikipedia.org/wiki/GOST_(block_cipher)

Is the IETF validating its use?

The GOST document is categorized in the same way as the one currently being debated/discussed: Informational. It also has "N" under the "Recommended" column (like ML-KEM-only will have):

* https://www.iana.org/assignments/tls-parameters/tls-paramete...

[ekr____]

In fairness, I do think that this situation is somewhat different. As I noted above (https://news.ycombinator.com/item?id=48812792), there are two main routes to an Informational RFC of this kind.

* Through the IETF

* Through the Independent Stream

The GOST documents went through the Independent Stream and therefore do not have IETF imprimateur. These documents are proposed for the IETF Stream and therefore require IETF Consensus to publish.

I know this is all super confusing. The basic problem is that the vast majority of RFCs come out of the IETF and so people often act as if all RFCs do. This is of course in part why people pursue Independent Stream publication rather than just publishing things on their own..

[throw0101d]

I have gotten flack for giving ULA+NPTv6 as a possible solution to an IPv6 multi-homing issue because the RFC that describes it was 'only' "Experimental":

* https://datatracker.ietf.org/doc/html/rfc6296

When I pointed out that the NAT(44) RFC (1631/3022) was 'only' "Informational" I got radio silence:

* https://datatracker.ietf.org/doc/html/rfc1631

[eqvinox]

> The question at hand is whether the IETF will publish an RFC documenting the ML-KEM.

The IETF document only documents how and where to put the MLKEM values into TLS. MLKEM itself is specified in FIPS203 and it just references that for the actual cryptographic details. The IETF document is in fact quite short:

https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-08.html

(This doesn't mean the document is a stub or pointless or something like that, you do need a "what goes where".)

[ekr____]

You're right. Bad writing on my part. Edited to make it clear.

[wbl]

The ISE has said they aren't progressing crypto drafts anymore.

[yasaheblasa]

You are simplifying ad absurdum. The NSA is as likely to compromise hash and signing algorithms as the police are likely to recommend pissing in petri dishes to cast doubt on that troublesome forensic science. The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber. Estimates at one point were that they had more than half of appropriate PhD level Mathematicians in the US, that may have gone down with more cryptocurrency firms, etc, but those firms are not researching algorithm families that may or may not replace the standards with all that much interest.

[tptacek]

The NSA had nothing to do with designing Kyber.

[protocolture]

He didnt say it did, he said "The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber"

[tptacek]

He himself (co-)submitted a lattice KEM to the NIST competition.

[nullc]

Yes, and strongly argued against lattice schemes generally. DJB submitted a lattice scheme under the theory that if the advocates of lattice schemes were able to win the argument about the performance properties then there should be a choice of an extremely conservatively designed one.

DJB himself has consistently advocated for Classic McEliece in any application which can accept its performance characteristics (which are excellent except for the ginormous public keys), and spent many bytes trying to convince people that the set of applications that can is wider than they suspect.

[mswphd]

NTRU based schemes are not the most conservative. NTRU is an old design from the 90s, that had some shocking structural attacks against it appear ~2016. These attacks so far are only relevant for moduli q ~ (1/100) n^{2.3...}. This makes them worse than conventional attacks against NTRU-based PKE. But they completely killed roughly half of all NTRU-based fully homomorphic encryption schemes, and are a (major) structural issue with NTRU that RLWE/MLWE does not have.

In other words, Bernstein proposed a NTRU-based scheme under his theory it was the most conservative. The only major attacks on lattice-based schemes since his proposal have been on the hardness assumption his scheme uses. I would personally suggest this means that Bernstein is not an accurate predictor of the security of lattice-based schemes. So far his track record (with this notable example, but also many others) is remarkably bad.

[tptacek]

His isn't the most conservative lattice construction! This is a hell of a just-so story.

[teravor]

    > Unfortunately, we can't yet say that about lattice cryptography, despite it being approximately as well-studied as ECC.

this is an absurd claim, lattices may be as well studied as elliptic curves, but not the cryptography.

[tptacek]

No, it's not an absurd claim. Lattice key establishment goes back into the mid-1990s, and was at one point a serious contender for the alternative-to-RSA/FFDH algorithm that ECC became. Modern LWE lattice KEM is approximately at the same point in its lifecycle (say, compared to original NTRU) as Curve25519 was to ECDH.

[adrian_b]

It does not matter much how long it goes back, because before its standardization very few people have bothered to study it.

Like for any other cryptographic algorithms, where one or more decades were necessary for a good understanding of their properties, we can expect much more relevant publications about lattice key establishment in the next years, than until now.

[mswphd]

this is entirely wrong. Lattice-based cryptography has been extremely well-studied theoretically and practically, even before standardization. For example, a (hybrid) lattice-based KEM was (experimentally) deployed in Chrome in 2016.

https://security.googleblog.com/2016/07/experimenting-with-p...

one or more decades were required to get good understanding of the relevant lattice problems. But they were introduced in

* the ~1990s, for NTRU, and * ~2005, for LWE, and * ~2012, for RWLE

ironically, of all of them LWE is probably understood the best (though our understanding of LWE, RLWE, and MLWE are all roughly similar now). This is because it is a problem more amenable to understanding than NTRU, which is (by comparison) a little more "ad hoc".

For lattice-based KEMs, we also have very strong understanding of things. Roughly, we were able to design the lattice-based KEMs based on our prior understanding of general KEMs. Concretely, we had a much better understanding of the precise details of the FO transform, which fed into teh design of lattice-based KEMs. So most lattice-based KEMs solely had to construct a lattice-based PKE. Doing so from LWE is fairly straightforward. Iirc since ~2005 there was a certain technique known, and then a more optimized technique was developed in ~2011. All lattice-based KEMs (that construct IND-CPA PKE -> FO Transform -> IND-CCA2 PKE) proceed with this ~2011 technique, with various internal knobs tweaked.

Post-standardization there has been some additional research into lattice-based KEMs, but they have (generally) been proceeding by tweaking the core ~2005 hardness assumption to try to get more efficiency. It's an interesting idea, but generally hardness assumptions take the longest time to gain confidence out of any part of a cryptographic algorithm (as they're the only unprovable part), so it might be a bit before we feel "safe" regarding them.

[teravor]

the McEliece cryptosystem goes back to the 70s, doesn't mean it's as well studied as RSA. obviously people study popular cryptographic primitives more.

having said that, I would trust McEliece more than Kyber.

[mswphd]

you would make poor decisions then. McEliece recently (in the last month) had a large new attack against it

https://eprint.iacr.org/2026/1232

This doesn't hit classic McEliece yet, but is part of a line of work that Randriambololona has been doing, which are at a minimum very concerning for the security of McEliece.

[teravor]

certainly a concern, and a good reason to use multiple cryptosystems together. unfortunately there are probably similar papers for Kyber which are NSA property and will never see the light of day. they do employ a lot of mathematicians.

for applications where key exchange need not be particularly fast or compact, I would even throw in 4096 MP-RSA in (tuned to whatever size the exchange can tolerate) as a hedge against that if a CRQC is even possible, it would be able to continue to grow in size quickly or at all.

[mswphd]

there is no indication there are similar papers. Curiously, the best lattice cryptanalysts in the world are chinese and european (here I'm thinking of people like Ducas, Albrecht, and Ding). It's actually a weird blindspot of american cryptography (this isn't true for all cryptanalysis, but in general European cryptography is "more concrete" vs "theoretical" american cryptography).

This isn't to say that it is impossible for the NSA to have their own private cryptanalysis. It is to say they're not some magical fairy that produces non-trivial attacks. They, like any other organization, need to develop talent. In the past they have been able to do this (they, through the CCR, hired Don Coppersmith in 2005. A VERY notable cryptanalyst at the time). I am unaware of any lattice cryptanalysts who have "gone dark" in a way similar to how Coppersmith did in ~2005.

Note that we also have theoretical reasons to be more confident in the hardness of ML-KEM. The reasons are technical (and worse than the practical reasons we have, namely people have iterated on attacks and the attacks stopped getting appreciably better). But it is (curiously) the hardness assumption we perhaps have the best (theoretical) justification for why it is hard.

Using RSA as a hedge would be incredibly stupid. Index calculus attacks were significantly improved in the 2010s, at least for small characteristic finite field DH. These improvements have only tangentially hit RSA. I've heard a integer factorization record holder directly say there's no real barrier to similar improvements hitting factoring. It hasn't been done, so it isn't "easy". But also people wouldn't be surprised if it was done. The record for binary characteristic finite field DH is ~30k bits (by an academic team. governments could throw more money at it of course).

[mswphd]

as a heads up, there is another attack paper against McEliece today

https://eprint.iacr.org/2026/1339

Note that this is by someone from the BSI. It's worth mentioning the BSI is very familiar with lattice-based schemes (they recommend using FrodoKEM rather than Kyber, but whatever). Despite this familiarity, the attacks they are able to publish aren't regarding lattice-based schemes, and instead a different scheme Bernstein was affiliated with.

NTRU-derivatives and McEliece derivatives are (objectively speaking) not a good track record to have, PQC-wise.

[tptacek]

You would trust McEliece more than Kyber because...

[grayhatter]

Because NIST chose it, after non-public input from the NSA. But if I am honest, NIST recommending it at all is enough to suspect it of being compromised. I say that as an American, and my non-american friends equally don't trust NIST on crypto topics.

The real problem I have is best described as I haven't read a single coherent argument responding to and rejecting the real concerns raised by the individual who after nist betrayed the internet with by recommending a compromised standard at the encouragement of the NSA. Is the person who wrote the crypto library everyone uses.

DJB puts his money (time) where his mouth is. I would critique his attachment to his own ego. But I'm in the group of people who haven't contributed enough yet to foss to get to throw stones. So I'll defer to people who can match his contributions. Until that happens, DJB's reputation is cares passionately about crypto and it's community, vs an US government group with a reputation for trying to sabotage crypto systems after passing secrets with the NSA, who refuses to provide details about their most recent secret messages.

I do find some of the arguments and refutations from the mailing lists compelling. But not all the them, and nothing directly from NIST. Equally some of DJB's appear to weaken his points. But like I said, I plan to trust the reputation each party has earned.

NIST has a history of behaving inappropriately, and unethically around it's cryptography recommendations. But the people currently in charge would rather pretend they're above it and not literally directly responsible for the organization with a well earned reputation. If you're given a 2nd chance after your partner catches you cheating, it's a reasonable requirement that you account for every second of your time, until you restore the reputation you destroyed.

[some_furry]

> But if I am honest, NIST recommending it at all is enough to suspect it of being compromised.

NIST isn't the NSA and doesn't have the NSA's goals in mind. They are briefed by NSA on some matters, sure, but they're not the same organization.

NSA has a dual mission: Both SIGINT and COMINT. While the SIGINT folks might rub their hands and laugh evilly at the prospect of backdooring the PQ KEM that the Internet wants to move towards, this plot makes no sense at several levels.

The NSA has, through CNSA 2.0, committed to moving the entire federal government onto ML-KEM for top secret communications. The COMINT guys would shit themselves in rage if it turned out to be backdoored, even if there was enough hubris that the backdoor was NOBUS.

If you can't trust the people, you should always seek to understand their incentives if you want to predict their behavior.

My interpretation of the CNSA 2.0 move was that the NSA believes 1) that ML-KEM is actually the good stuff, and 2) the Suite B transition failed so spectacularly that they want to signal confidence in ML-KEM by recommending it without hybridization. Since pretty much everything they do is top secret, they probably can't comment further.

[tptacek]

This argument is entirely non-falsifiable. You could use the same logic no matter what algorithm won the PQC competition. You can even use Vizzini logic to argue against against algorithms the NIST competition didn't pick.

[mswphd]

if you blindly distrust the NSA, you should stop using x25519 immediately. It uses SHA2, which was solely developed by the NSA.

If DJB blindly distrusts the NSA, he would also recommend against SHA2. But he doesn't, and instead wants to mix a scheme developed by European academics with one built by the NSA. If you go by blind distrust, this should be extremely concerning.

Of course, I'm not suggesting you use blind distrust, and only pointing out that none of the blind distrust discourse makes any sense. We all trust SHA2, which was an explicit NSA product. Kyber had no NSA input. why is Kyber the NSA-suspect scheme?

[dhx]

To extend on this good point--

DJB is not just a mathematician looking over theoretical equations. He's also an expert in the real world _implementation_ of cryptography where most security failures can be expected to occur.

For some mathematician's brilliant cryptography scheme, how easy would it be for implementers to develop constant time / constant power computer algorithms to avoid side channel leakage? Have these computer algorithms been developed, are they easy to implement securely or are implementers going to continually mess it up?

See [1] and [2] for answers. Summary: Technology is not ready.

[1] https://dl.acm.org/doi/10.1145/3569420

[2] https://dl.acm.org/doi/10.1145/3779208.3785290

[tptacek]

He's a cryptographer. You're describing cryptographers. You get that other cryptographers designed Kyber/MLKEM, and still more implemented it, right? There are cryptographers besides Daniel J. Bernstein.

[eqvinox]

I do think it's fair to make an argument that DJB's expertise in practical cryptography (both in e.g. engineering against side channel attacks as well as in publishing his own libraries) gives him a reality-minded perspective/attitude.

That said, personally speaking, his behavior as a software publisher (packaging & whatnot) is something I'd call… let's go with "subpar" and leave it at that. So while I do believe it's a fair argument, I'm not accepting it, because from my perspective he isn't putting in the necessary work to really understand software publishing.

[adrian_b]

Bernstein as a "software publisher" cannot really be compared with anyone else, because what can be considered as great flaws in comparison with others are compensated by equally great advantages.

He has published a very large quantity of open-source software, but after publication he never bothered with any kind of maintenance, which is understandable, because he went on doing other work.

On the other hand, unlike almost any other software packages, those published by him almost did not need any maintenance. The only required changes, after decades since they were written, have been caused by external changes, e.g. the continuous evolution and instability of the Linux APIs and the replacement of various IETF RFCs.

I am still using several software packages written by DJB, which have been run continuously 24/7 for more than a quarter of century, on many servers, without ever causing any kind of problems or incidents, unlike a lot of much more notorious software packages, which had various bugs despite permanent maintenance.

[tptacek]

The problem here is that for too many people, Bernstein is one of two living cryptographers with name recognition.

[eqvinox]

Ah I see what you were trying to say. It read to me (with "He's a cryptographer. You're describing cryptographers.") like you were dismissing that knowledge about implementing and shipping cryptographic libraries is a relevant expertise (or that every cryptographer would have that, which they absolutely don't.) But, yeah, he's one among a whole bunch of experts in some of these fields and certainly shouldn't be given special weight just due to his name recognition.

[g-b-r]

"two timing leaks, KyberSlash1 and KyberSlash2, in every official reference Kyber implementation from 2017 through late 2023"

Cryptographers can be good, bad, be more or less knowledgeable about applied cryptography, and possibly have agendas.

[tptacek]

Huh, seen through that light, it's much clearer why we should all have ECC in our cryptosystems, because nothing has ever gone wrong with an ECC implementation.

[g-b-r]

We do all have ECC in our cryptosystems right now, and given how long it's been there, we can rely on its security much more than something new.

[dhx]

This reads to me as an argument of "If you thought ECDSA was bad, wait until you see MLKEM?"

ECDSA history is repeating itself again when you consider how poorly the proposed MLKEM RFC deals with side channel resistance:

From draft-ietf-tls-mlkem-8:[1]

"Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."

From NIST SP 800-227:[2]

"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."

MLKEM is more complex and has more chances of stuff-ups in implementation than ECDSA did. A single sentence of encouragement is all that is on offer from this MLKEM RFC. It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]

As a point of reference for how hard it is to implement side channel resistant MLKEM see [4] (formal verification) and [5] (errors in formal verification). The MLKEM RFC doesn't offer a "Security Considerations" section to explain how difficult it is to implement side channel resistant MLKEM (perhaps it's easy :S), and if it were hard to implement, to recommend use of EdDSA+MLKEM for cryptography implemented on devices an attacker may be able to physically access, or when used on public networks as a workaround given that side channel resistant EdDSA would be easier to implement.

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1

[4] https://github.com/pq-code-package/mlkem-native/tree/main/pr...

[5] https://eprint.iacr.org/2026/192

edit: added reference 5

[dhx]

Not all cryptographers (and cryptography standards) care about real world implementation, or have the same use cases in mind for their cryptography algorithms and protocols. Almost every cryptography standard in common use treats side channel resistance as an optional after-thought for implementers. This might be fine for some users, for example, the US government, because they generally don't implement cryptography on systems an attacker would have physical access to, and don't use cryptography protocols on public networks. For these users, having maximum performance at the expense of side channel resistance might be the best trade-off to make.

For most users however, side channel resistance is a very important property that shouldn't be considered an optional after-thought. If standards bodies made it mandatory to consider side channel resistance when standardising cryptography schemes, the choice of what scheme(s) to standardise could look quite different, and thus general use of cryptography would have improved security by default. If some types of users don't care about side channel resistance, then great, make use of non-side-channel-resistant cryptography optional for them to use. Don't standardise it the other way around.

For example:

FIPS 186-5 sB.1 states: "Other (constant time) algorithms that produce an equivalent result may be used."[1]

NIST SP 800-186 sE.4 states: "If one is concerned about side-channel leakage, one should compute the inverse using a constant-time algorithm."[2]

RFC 8032 s8.1 states: "Note that the example implementations in this document do not attempt to be side-channel silent."[3]

A better standard may, for example, _require_ [4] be implemented in order for an implementation to claim conformance with the standard. Not as an optional after-thought. If there are users wanting to trade off side channel resistance for performance gains, then write a new standard to that effect and remove the requirement to implement [4].

A better standardisation process may, for example, only accept candidate algorithms _if_ they are side channel resistant. This opens up the standard to as many use cases as possible. No cutting corners to pretend performance is better for one implementation because it trades off side channel resistance for performance, and no pretending side channel sensitive use cases don't exist.

[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1

[4] https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplic...

[tosti]

I, for one, wouldn't care if Kanye West or his aunt or her neigbours dog came up with a good encryption algo. If it's good, it's good no matter who wrote it. Appeals to authority or the lack thereof draws attention away from the technical debate.

[throw_a_grenade]

Unfortunately, that's not how modern crypto works. Many mathematical problems on which algorithm rests their security are not proven to be unsolvable, but instead they're believed to be hard to solve. So here are the questions, who believes what is hard, and hard for whom.

Somehow I wouldn't trust my data on mathematical problems, for which the recommendation is that they would challenge Kayne West.

[rasengan]

I certainly find it fascinating that the majority of those in favor come from signal intelligence agencies, while the majority of those against are PhD cryptographers.

I was happy to see the lead of Europe’s PQC team also voted with the cryptographers.

[g-b-r]

> nothing that's happening here has really anything to do with NSA

How can you say that???

It seems to be literally only for their claim to need it that pure MLKEM is being requested..!

A summary at https://blog.cr.yp.to/20251004-weakened.html, or just see e.g. https://keymaterial.net/2025/11/27/ml-kem-mythbusting for an opposite voice stating the same...

[nullc]

I might have expected you'd be once bitten twice shy after having once taking an aggressive position that DUAL-EC would never have backdoored anyone in practice...

The optionality of MLKEM by itself is of a similar shape to standardizing a lame DRBG that 'obviously' no one would use and anyone who would use would use the appendix parameter generation scheme that would have rendered it secure (although still slow). The reality of it was that once it was standardized NSA was able to secretly compel its use.

On one hand MLKEM by itself seems like a better choice than DUAL-EC, on the other hand that fact should make it much easier for a powerful attacker to cause a target to use it if you do have an attack that exploits this fact.

MLKEM was selected out of myriad other options through a NIST process which was directly influenced by NSA (including in manners that NIST failed to disclose and actively mislead the group about). I think this makes the commentary regarding NSA highly relevant. While it seems less like that NSA already knows of a total break in MLKEM (and indeed their influence could have been in a strengthening direction...) it's possible that their influence was motivated by things like that ease of undetectably compromising specific implementations through techniques like dopant adulteration or specialized side channel weaknesses.

If your plan it to tamper with chip mfgr or hit them with a very well aimed e-beam (e.g. to cause ion migration) after the fact then having a non-hybrid scheme is pretty obviously going to make your life much easier... Or perhaps they've taken a route similar to the one they took with Crypto AG-- this time positioning themselves as a fabless silicon vendor to sell MLKEM RTL to a market that doesn't have an implementation but already has many robust ECC implementations to choose from.

...and that's without getting into the unknown possibility of a cryptoanalytic breakthrough.

I don't think it's even safe to say that NSA would only consider NOBUS backdoors-- I don't think any of us can know how inadvisably arrogant the relevant decision makers may be and what they might consider NOBUS. Given how DUAL_EC went in Netscreen's products I think it's reasonable to argument that there is no such thing as a NOBUS backdoor when push comes to shove. Capping DES's key size is candidate example of a very much non-NOBUS weakness that NSA felt comfortable with, as one needed a particularly amount of strength to exploit it which they believed that only they had. Today, of course, a child's video game device can crack DES as a direct product of that part of their influence.

Not a great track record when fear of "store and decrypt later" attacks is much of what motivates the use of PQ key agreement today.

The consistent aggression five-eyes affiliated cryptographic-intelligence groups have had for hybrid schemes is truly difficult to comprehend-- given that practically everyone else considers them obviously prudent in all cases where the resource costs permit -- and I think this justifies the utmost concern and caution. And in terms of caution hybrid schemes are table stakes.

A major theme of DJB's cryptographic security advocacy is that cryptographic security is often as much about what you don't offer as it is what you do. A completently engineered security product is misuse resistant and it's not completely clear to me that a standard which offers the choice of a non-hybrid mlkem qualifies as misuse resistant.

That said, there are plenty of drafts that are in no way misuse resistant. :)

[tptacek]

None of this makes any sense once you understand that NSA had no hand in designing MLKEM, or in shaping the LWE research that led to it. NSA designed Dual-EC. MLKEM won an open competition; its entrants are among the most reputable cryptographers in the world.

[nullc]

Post selection is also design. Evolution by natural (or artificial, for that matter) selection works by post-selection.

I'm happy to agree that it affords much less degrees of freedom than original design, but the irrelevance argument depends on no influence rather than a lack of absolute influence.

[tptacek]

I'd call this an instance of the genetic fallacy, but it's even less tethered to reason than that.

[mswphd]

it's worth clarifying that its entrants were all qualified, and 2 other essentially identical schemes, namely New Hope and Saber, made it very deep into the NIST competition.

All 3 (roughly) took the approach of

1. take the obvious best design, and

2. tweak various internal design knobs you have access to, and

3. that's pretty much it.

So they differ in the internal design knobs they chose. But the fact that 3 independent teams all created something substantially similar to ML-KEM should be an indication of how much harder it would be for the NSA to be behind it.