10 ms·

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 c

• ekr____ 4mo ago
  > (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-parameters.xhtml#tls-parameters-8 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-submissions/ 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/ 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.
  • wbl 4mo ago
    The ISE has said they aren't progressing crypto drafts anymore.
  • eqvinox 4mo ago
    > 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 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____ 4mo ago
      You're right. Bad writing on my part. Edited to make it clear.
  • throw0101d 4mo ago
    > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 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_vi57ceVcfmA75Hs/ https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...
    • chrismorgan 4mo ago
      > 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.
• teravor 4mo ago
  > 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.
  • dhx 4mo ago
    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 https://dl.acm.org/doi/10.1145/3569420 [2] https://dl.acm.org/doi/10.1145/3779208.3785290 https://dl.acm.org/doi/10.1145/3779208.3785290
    • tptacek 4mo ago
      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 4mo ago
        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.
• g-b-r 4mo ago
  > 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 https://blog.cr.yp.to/20251004-weakened.html, or just see e.g. https://keymaterial.net/2025/11/27/ml-kem-mythbusting https://keymaterial.net/2025/11/27/ml-kem-mythbusting for an opposite voice stating the same...
• yasaheblasa 4mo ago
  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 4mo ago
    The NSA had nothing to do with designing Kyber.
    • protocolture 4mo ago
      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 4mo ago
        He himself (co-)submitted a lattice KEM to the NIST competition.
        • nullc 4mo ago
          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.
• rasengan 4mo ago
  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.
• nullc 4mo ago
  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. :)
• chr15m 4mo ago
  [flagged]
  • acdha 4mo ago
    You’re being rude, which wouldn’t be good even if you weren’t wrong on all three counts. This is not contriving positively. (Consider the difference between extensive peer-review and “appeal to authority”, not to mention the IETF’s dual role encouraging research along with mainstream deployments)
    • chr15m 4mo ago
      I have edited my post to remove the rude acronym. Thank you for your feedback. I do not think the response addresses the claims made, and uses logical fallacies in place of a well reasoned response. > a team of highly-regarded European academic cryptographers This is absolutely an appeal to authority.
      • acdha 4mo ago
        They didn’t get MLKEM deployed by saying “I’m a professor of computer science at $UNI, do it!” but by working within the community for many years and going through an elaborate review and standardization process with extensive peer review and public comment. That’s not infallible but it’s misleading to talk about it as if it’s the same as the U.S. federal government (a real capital-A authority) mandating it. This matters because academic reputation is so important in the field: none of these people can force even their own universities to adopt something and if you say they pushed something through covertly you’re making a really serious claim about a core professional trait which reflects not only on them but also many of their colleagues who reviewed and supported that proposal, and that should have evidence that this was bulled through rather than simply asserting it.
        • chr15m 4mo ago
          Correct. The argument is not about the deployment or the technical quality of MLKEM. Pretending it is, is an appeal to authority, and is moving the goal posts from the actual argument.