9 ms·

NSA and IETF: Fairness

147 points by WatchDog 2mo ago

lprimeisafk 2mo ago
Disappointed that there is not more discussion about this as this looks to be a slow march to the government getting its way with a technology that will affect so many.
anonym29 2mo ago
Highly recommended reading for effectively understanding the behavior patterns of bad-faith participants in such exchanges: https://www.scribd.com/document/345154863/Guide-to-Forum-Spies-and-Trolls https://www.scribd.com/document/345154863/Guide-to-Forum-Spi... If the link goes down, the content is available in many other places across the web under the title "The Gentleman's Guide To Forum Spies (spooks, feds, etc.)"
- eqvinox 2mo ago
  From the other direction, the ITU-T has a highly regarded presentation on how to actually work with consensus procedures & establish said consensus: https://www.itu.int/en/ITU-T/tutorials/202203/Documents/Reinhard%20Scholl_v2_The%20art%20of%20reaching%20consensus.pdf https://www.itu.int/en/ITU-T/tutorials/202203/Documents/Rein...
eqvinox 2mo ago
DJB keeps calling the IETF consensus process "voting". That's detrimental to his own case; when there is a vote, the vote can be manipulated. It makes much more sense to argue there is no consensus, which should be quite obvious at this point, and which can be argued even in a "60:40" situation regardless of direction. It also avoids alienating "true IETF believers" (ed.: I am one). Apart from that, the crux of this is the codepoint allocation in the named group registry. [https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 https://www.iana.org/assignments/tls-parameters/tls-paramete...] The requirement for that allocation (with "recommended=N" - which is what this draft has) is "Specification Required", not "IETF consensus". "Specification" for IANA registries doesn't mean IETF documents, it means: […] must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. [https://datatracker.ietf.org/doc/html/rfc8126#section-4.6 https://datatracker.ietf.org/doc/html/rfc8126#section-4.6] As such I don't understand why the authors are so intent at ramming this through the IETF process when they could just put the same document whereever. The process has been sufficiently and publicly fraught enough to destroy any "reputation" that might (or might not) come associated with it being published as IETF RFC. [ed.: referenced wrong registry, it's named groups, not cipher suites. Makes no difference, same registration procedure.] FTR, the only [preliminary] entry with recommended=Y for PQ crypto is: 4588 X25519MLKEM768 Combining X25519 ECDH with ML-KEM-768 https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-mlkem-05 [ed.2: this is getting a funky spread of up & down votes, any of the downvoters mind commenting why they're downvoting?]
- ekr____ 2mo ago
  Adding a little color here... There are already code points registered for pure ML-KEM on the basis of the draft. The hybrid code point you reference is "preliminary" in the sense that when the RFC for hybrid ECC/ML-KEM is published (it's already been approved, https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/), it will replace the reference in the registry. However, it will have the same code point and the same semantics. If, for some reason, the IETF were to change the semantics, a new code point would have to be assigned for interop reasons.
  - eqvinox 2mo ago
    > […] "preliminary" in the sense that when the RFC for hybrid ECC/ML-KEM is published […] Yes, sorry, I was just covering against people nitpicking on the document status :)
  - eqvinox 2mo ago
    Actually… what would even be the result of the pure MLKEM document getting dropped by the IETF? I guess the entries would temporarily be marked deprecated or something, until another reference is made available somewhere, describing the same behavior? I'm not sure what procedural blockers this might run into but my general sense is that the IETF & IANA wouldn't "block off" the already allocated codepoints from being specified elsewhere (or allocate new duplicate codepoints) so long as the behavior is identical.
    - ekr____ 2mo ago
      Good question. If the document is dropped by the IETF, nothing at all would happen. It's already a valid code point registration, and indeed the authors could have just published the document, registered the code points, and stopped (see: https://datatracker.ietf.org/doc/draft-barnes-tls-this-could-have-been-an-email/ https://datatracker.ietf.org/doc/draft-barnes-tls-this-could...). If the authors decided to later pick up the document somewhere else, then they could probably get the reference changed to whatever that was, as long as the semantics were identical.
avidiax 2mo ago
This post was pretty technical. Let's explain a couple of terms: ML-KEM -- Module-Lattice-Based Key-Encapsulation Mechanism ML-DSA -- Module-Lattice-Based Digital Signature Algorithm solo PQ -- Using post-quantum crypto on its own ECC+PQ -- Using post-quantum crypto as a layer on top of traditional elliptical curve cryptography (ECC) So what's at stake here, is that the PQ crypto is not proven yet, and had recent implementation vulnerabilities (Kyberslash 1 & 2). In the NSA's defense, combining cryptosystems also creates attack surfaces, timing problems, additional complexity, etc. Perhaps they know something we don't. They have sometimes acted to strengthen public cryptography, as with the DES S-boxes and differential cryptanalysis. Of course, they also weakened the key-space...
- g-b-r 2mo ago
  > Perhaps they know something we don't Perhaps https://blog.cr.yp.to/20260704-bugs.html#damage https://blog.cr.yp.to/20260704-bugs.html#damage
- rasengan 2mo ago
  > In the NSA's defense, combining cryptosystems also creates attack surfaces, timing problems, additional complexity, etc Actually, Dr. Nadim Kobeissi formally proved that hybrid is secure, even if ML-KEM fails. [1] [1] https://eprint.iacr.org/2026/1147 https://eprint.iacr.org/2026/1147
- mswphd 2mo ago
  1. Kyberslash is mostly marketing. Some implementations (including the Kyber reference implementation, but *not* including the Kyber AVX implementation) had a non-constant time component. This is a meaningful CVE. It is not some fundamental weakness that should cause a panic. Note that the non-constant time implementations were caught ~2 years ago, prior to any deployment. So it was a sign of everything going "as expected", not of some new fundamental issue. 2. combining the cryptosystems, in most settings, is rather low cost. I would personally recommend it as a sensible default. It is not low cost in every setting though, for example in hardware it necessitates both a SHA2 and SHA3 impl, which is fairly expensive. So while hybrids are a sensible default, I would not go as far as to attempt to "ban" use of pure ML-KEM. 3. pure ML-KEM is much more "proven" than people are discussing. The core hardness assumption dates back to 2005, and has been intensely studied (the paper introducing it got a cryptography version of a Nobel prize (Godel prize), as did several follow-up works only achievable using that hardness assumption. The essential components of ML-KEM were proposed in ~2011. An extremely similar scheme (New Hope) was deployed experimentally in a hybrid in Chrome in 2016. Very concretely, the best theoretical attacks on ML-KEM take time ~2^cn for a c that has not changed in the last ~decade. Everything is as boring as you might hope. On essentially any reasonable measure you could ask for, things have been "stable" with ML-KEM for ~1 decade. In the intervening years, a number of academics/companies have devoted a great deal of money on things built from even more sketchy hardness assumptions (I'm discussing the things underlying Fully Homomorphic Encryption). Even these have been essentially fine (I have some personal quibbles with some assumptions used, though they are technically dense, and are not relevant to ML-KEM in the slightest). So this is to say that there are natural "easier instances" of the thing underlying ML-KEM, and there still haven't been successful attacks of those instances. Anyway though, the question isn't "should you use pure ML-KEM rather than hybrid". I would personally suggest hybrid unless it is extremely limiting for some particular scenario (and there are scenarios, such as hardware, where it is). The question is "should we standardize how pure ML-KEM TLS works, so implementors can create interoperable implementations?". The answer to this should (clearly) be yes. ML-KEM is boring, high-quality cryptography. If a quantum computer appeared tomorrow, and only ML-KEM protected me, I would not lose any sleep personally. Efforts to delay standardization rely on "arguments" that do not match reality in the slightest.
JumpCrisscross 2mo ago
> Secret NSA documents showed that NSA pushed DES in the 1970s to "drive out competitors" while knowing that DES was "weak enough" to break; meanwhile NSA publicly claimed that it would use DES Is this true? The NSA pushed for weaker cryptography it could break versus stronger cryptography our adversaries couldn't?
- tptacek 2mo ago
  It's complicated. The federal government pushed for a smaller DES key size, but also fixed the DES s-boxes to resist differential cryptanalysis.
- rurban 2mo ago
  Sure. Everbody knows that
- mswphd 2mo ago
  as mentioned it's complicated, but the general trend of the NSA pushing cryptography they can break and others can't is well-known. https://en.wikipedia.org/wiki/NOBUS https://en.wikipedia.org/wiki/NOBUS note that there is no even candidate way the NSA would have a NOBUS-type vulnerability for ML-KEM. DUAL_EC_DRBG was known to plausibly have a NOBUS-style backdoor prior to standardization, provided you used a certain "default" generator (vs freshly generating your own). It was later discovered that the NSA payed RSA (the company) to do this. While this payment was private, the possibility of a back door was publicly known. There are no publicly known candidate backdoors for ML-KEM. The broad design of an ML-KEM-like scheme permits one ("static" matrix A), but ML-KEM was specifically designed to make this impossible ("ephemeral" matrix A).
- philodeon 2mo ago
  DJB wrote a short history of NSA’s malicious meddling in the cryptography we all use, based on a declassified internal history of the NSA. https://blog.cr.yp.to/20220805-nsa.html https://blog.cr.yp.to/20220805-nsa.html
tptacek 2mo ago
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____ 2mo 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.
jauntywundrkind 2mo ago
Is there anything different about this DJB mailing list brigading than the other brigading he's done? Four days ago: https://news.ycombinator.com/item?id=48760490 https://news.ycombinator.com/item?id=48760490
- tptacek 2mo ago
  By dint of not including a list of non-cryptographer cosigners, this one is prima facie somewhat less cringe.
iririririr 2mo ago
if i were the nsa, I'd have spent all my research money on attacking ecc+pq, because 1. no self respecting security engineer would deploy bare pq (see cloudflare), 2. no phd research team would attack the combination (well, not before until it's too late) because that's harder than a phd requires (they will target solo pq or solo ecc). 3. it's much easier to "sell". q.e.d. this article.
- maqp 2mo ago
  Probably not. It's been ~13 years when Snowden said what the NSA is doing is going around the encryption by hacking endpoints. Post quantum cryptography doesn't change any of that. You can still lift TLS keys with exploits for transparent MITM. I'd imagine it's much better ROI to look for vulnerabilities with Mythos, than to attack the algorithms.
  - g-b-r 2mo ago
    > is going around the encryption by hacking endpoints Because they weren't (supposedly) able to break the encryption > than to attack the algorithms You have an opportunity to introduce new, broken, algorithms; they exploited it with DES, tried to exploit it with ECC, why wouldn't they try it with post-quantum (which they've kind of been pushing)?
    - maqp 2mo ago
      What's the vulnerability they injected into DES?
- tptacek 2mo ago
  This is completely backwards. The more cryptography-literate you are, the more likely it is you think hybrids are silly. Plenty of cryptographers think this is all bullshit, and that ECC+MLKEM makes about as much sense as an AES+Serpent cascade. It is simultaneously the case that MLKEM is far less mysterious than programmers on message boards think it is, and that conventional ECC and finite field cryptography is much more mysterious and spooky than they think it is. (I'm only somewhat cryptography-literate and so I would myself default to a hybrid, though that opinion might change the first time I bother banging together an MLKEM implementation.)
yardstick 2mo ago
DJB has orchestrated a vote rigging campaign against this WGLC, encouraging users to join the list and vote/express their opinion and providing the exact subject header to use. Have any other sides been saying, essentially, just join the group and say you’re for/against? He’s been moderated during the last call because of his email disclaimer/footnote, and apparently refuses to respond on list during this time. Seems like he’s playing a few steps ahead where he can (yet again) cry foul on the system and cry foul on vote rigging. Despite him being a key instigator. I’ve already seen at least one poster reference a RFC explaining how IETF consensus works and how its not a pure numbers game (5 for and 100 against can still be consensus, depending on the circumstances; the inverse also applies). What’s his next step if the authors publish as an information RFC? He can’t stop that, right?
- eqvinox 2mo ago
  > …information RFC? He can’t stop that, right? Informational RFCs still need to pass through the IETF consensus process, changing the intended status isn't a procedural bypass. However, the authors can just publish it elsewhere, it makes no difference at all for the codepoint allocations. Only distinction is that it doesn't get the somewhat intangible (but existent) "RFC sheen".
  - ekr____ 2mo ago
    This document actually is being advanced as Informational, though there are also non-IETF Informational RFCs (see upthread).
- ekr____ 2mo ago
  > What’s his next step if the authors publish as an information RFC? He can’t stop that, right? This is a slightly complicated question. There are several main routes to an Informational RFC. * Through the IETF Stream, either through the Working Group (what is happening now) or via sponsorship by an Area Director. The former is what is happening now (this document is not up for Proposed Standard). I don't think the latter is likely to happen if TLS WG decides not to publish. If the TLS WG does decide to publish, then there are a number of steps afterward (AD review, IETF Last Call, IESG Review), plus potential avenues for appeal at some of these stages. * Through the Independent Submissions Editor (ISE) (though in another comment wbl says that the ISE is not going to publish cryptography standards https://news.ycombinator.com/item?id=48812844 https://news.ycombinator.com/item?id=48812844). This is essentially at the sole discretion of the ISE and can't be appealed. In either case, if the document makes it through all these gates and is eventually published as an RFC, then that's pretty much it, as RFCs aren't changed once published.
g-b-r 2mo ago
To those who say that approving or not this RFC won't make any difference: «- Liaisons: We received liaison statements from multiple SDOs including O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing support for the publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF to provide a stable normative reference» (https://mailarchive.ietf.org/arch/msg/tls/ol2otAvtdDrdz_xY0_eKcuY1om0 https://mailarchive.ietf.org/arch/msg/tls/ol2otAvtdDrdz_xY0_...)
slim 2mo ago
MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe As you know, teams are vulnerable to infiltration and individuals to compromise. Corruption often stems from various motives, including ideology
- mswphd 2mo ago
  that's really not possible for ML-KEM. They took a well-known "boring" design, and tweaked certain internal sub-components of it. Their tweaks were good, and their analysis/exposition of it were good. So they deserve to win. But there were many essentially identical schemes (e.g. Saber and New Hope are essentially the same as ML-KEM). To infiltrate/compromise ML-KEM, then NSA would need to do something like 1. corrupt some europeans for the literal submission, and 2. corrupt the competing submissions, which are substantially similar, and 3. corrupt the entirety of the cryptographic community so they miss a flaw in the (extremely simple tbh) 2011 paper htat kicked off hte design. If a conspiracy requires corrupting a single person it's plausible. ML-KEM being intentionally weakend by the NSA would quite literally require corrupting like 100+ different people in different countries. it makes no sense.
thomasdeleeuw 2mo ago
France and Germany propose hybrid schemes as well: The german position: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat... "The quantum-safe mechanisms recommended in this Technical Guideline are generally not yet trusted to the same extent as the established classical mechanisms, since they have not been as well studied with regard to side-channel resistance and implementation security. To ensure the long-term security of a key agreement, this Technical Guideline therefore recommends the use of a hybrid key agreement mechanism that combines a quantum-safe and a classical mechanism." The french position, also quoting the German position: https://cyber.gouv.fr/sites/default/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf https://cyber.gouv.fr/sites/default/files/document/follow_up... "As outlined in the previous position paper [1], ANSSI still strongly emphasizes the necessity of hybrid wherever post-quantum mitigation is needed both in the short and medium term. Indeed, even if the post-quantum algorithms have gained a lot of attention, they are still not mature enough to solely ensure the security"
- tptacek 2mo ago
  The IETF already has a standard hybrid scheme and it's what everybody already uses. That's not what this is about.
potatototoo99 2mo ago
If a US three letter agency recommends it, I don't want it.
- some_furry 2mo ago
  Didn't the FDA used to recommend pasteurizing milk?
- mswphd 2mo ago
  the NSA also recommends elliptic curve cryptography, and designed SHA2 themselves. if you want we can talk through how to disable all of these ciphersuites, so you can be stuck with a bunch of shitty stuff from the 90s and feel warm and fuzzy about it.

147 points by WatchDog 2mo ago

Disappointed that there is not more discussion about this as this looks to be a slow march to the government getting its way with a technology that will affect so many.

anonym29 2mo ago

Highly recommended reading for effectively understanding the behavior patterns of bad-faith participants in such exchanges: https://www.scribd.com/document/345154863/Guide-to-Forum-Spies-and-Trolls https://www.scribd.com/document/345154863/Guide-to-Forum-Spi... If the link goes down, the content is available in many other places across the web under the title "The Gentleman's Guide To Forum Spies (spooks, feds, etc.)"

eqvinox 2mo ago
From the other direction, the ITU-T has a highly regarded presentation on how to actually work with consensus procedures & establish said consensus: https://www.itu.int/en/ITU-T/tutorials/202203/Documents/Reinhard%20Scholl_v2_The%20art%20of%20reaching%20consensus.pdf https://www.itu.int/en/ITU-T/tutorials/202203/Documents/Rein...

eqvinox 2mo ago

DJB keeps calling the IETF consensus process "voting". That's detrimental to his own case; when there is a vote, the vote can be manipulated. It makes much more sense to argue there is no consensus, which should be quite obvious at this point, and which can be argued even in a "60:40" situation regardless of direction. It also avoids alienating "true IETF believers" (ed.: I am one). Apart from that, the crux of this is the codepoint allocation in the named group registry. [https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 https://www.iana.org/assignments/tls-parameters/tls-paramete...] The requirement for that allocation (with "recommended=N" - which is what this draft has) is "Specification Required", not "IETF consensus". "Specification" for IANA registries doesn't mean IETF documents, it means: […] must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. [https://datatracker.ietf.org/doc/html/rfc8126#section-4.6 https://datatracker.ietf.org/doc/html/rfc8126#section-4.6] As such I don't understand why the authors are so intent at ramming this through the IETF process when they could just put the same document whereever. The process has been sufficiently and publicly fraught enough to destroy any "reputation" that might (or might not) come associated with it being published as IETF RFC. [ed.: referenced wrong registry, it's named groups, not cipher suites. Makes no difference, same registration procedure.] FTR, the only [preliminary] entry with recommended=Y for PQ crypto is: 4588 X25519MLKEM768 Combining X25519 ECDH with ML-KEM-768 https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-mlkem-05 [ed.2: this is getting a funky spread of up & down votes, any of the downvoters mind commenting why they're downvoting?]

ekr____ 2mo ago
Adding a little color here... There are already code points registered for pure ML-KEM on the basis of the draft. The hybrid code point you reference is "preliminary" in the sense that when the RFC for hybrid ECC/ML-KEM is published (it's already been approved, https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/), it will replace the reference in the registry. However, it will have the same code point and the same semantics. If, for some reason, the IETF were to change the semantics, a new code point would have to be assigned for interop reasons.
- eqvinox 2mo ago
  > […] "preliminary" in the sense that when the RFC for hybrid ECC/ML-KEM is published […] Yes, sorry, I was just covering against people nitpicking on the document status :)
- eqvinox 2mo ago
  Actually… what would even be the result of the pure MLKEM document getting dropped by the IETF? I guess the entries would temporarily be marked deprecated or something, until another reference is made available somewhere, describing the same behavior? I'm not sure what procedural blockers this might run into but my general sense is that the IETF & IANA wouldn't "block off" the already allocated codepoints from being specified elsewhere (or allocate new duplicate codepoints) so long as the behavior is identical.
  - ekr____ 2mo ago
    Good question. If the document is dropped by the IETF, nothing at all would happen. It's already a valid code point registration, and indeed the authors could have just published the document, registered the code points, and stopped (see: https://datatracker.ietf.org/doc/draft-barnes-tls-this-could-have-been-an-email/ https://datatracker.ietf.org/doc/draft-barnes-tls-this-could...). If the authors decided to later pick up the document somewhere else, then they could probably get the reference changed to whatever that was, as long as the semantics were identical.

avidiax 2mo ago

This post was pretty technical. Let's explain a couple of terms: ML-KEM -- Module-Lattice-Based Key-Encapsulation Mechanism ML-DSA -- Module-Lattice-Based Digital Signature Algorithm solo PQ -- Using post-quantum crypto on its own ECC+PQ -- Using post-quantum crypto as a layer on top of traditional elliptical curve cryptography (ECC) So what's at stake here, is that the PQ crypto is not proven yet, and had recent implementation vulnerabilities (Kyberslash 1 & 2). In the NSA's defense, combining cryptosystems also creates attack surfaces, timing problems, additional complexity, etc. Perhaps they know something we don't. They have sometimes acted to strengthen public cryptography, as with the DES S-boxes and differential cryptanalysis. Of course, they also weakened the key-space...

g-b-r 2mo ago
> Perhaps they know something we don't Perhaps https://blog.cr.yp.to/20260704-bugs.html#damage https://blog.cr.yp.to/20260704-bugs.html#damage
rasengan 2mo ago
> In the NSA's defense, combining cryptosystems also creates attack surfaces, timing problems, additional complexity, etc Actually, Dr. Nadim Kobeissi formally proved that hybrid is secure, even if ML-KEM fails. [1] [1] https://eprint.iacr.org/2026/1147 https://eprint.iacr.org/2026/1147
mswphd 2mo ago
1. Kyberslash is mostly marketing. Some implementations (including the Kyber reference implementation, but *not* including the Kyber AVX implementation) had a non-constant time component. This is a meaningful CVE. It is not some fundamental weakness that should cause a panic. Note that the non-constant time implementations were caught ~2 years ago, prior to any deployment. So it was a sign of everything going "as expected", not of some new fundamental issue. 2. combining the cryptosystems, in most settings, is rather low cost. I would personally recommend it as a sensible default. It is not low cost in every setting though, for example in hardware it necessitates both a SHA2 and SHA3 impl, which is fairly expensive. So while hybrids are a sensible default, I would not go as far as to attempt to "ban" use of pure ML-KEM. 3. pure ML-KEM is much more "proven" than people are discussing. The core hardness assumption dates back to 2005, and has been intensely studied (the paper introducing it got a cryptography version of a Nobel prize (Godel prize), as did several follow-up works only achievable using that hardness assumption. The essential components of ML-KEM were proposed in ~2011. An extremely similar scheme (New Hope) was deployed experimentally in a hybrid in Chrome in 2016. Very concretely, the best theoretical attacks on ML-KEM take time ~2^cn for a c that has not changed in the last ~decade. Everything is as boring as you might hope. On essentially any reasonable measure you could ask for, things have been "stable" with ML-KEM for ~1 decade. In the intervening years, a number of academics/companies have devoted a great deal of money on things built from even more sketchy hardness assumptions (I'm discussing the things underlying Fully Homomorphic Encryption). Even these have been essentially fine (I have some personal quibbles with some assumptions used, though they are technically dense, and are not relevant to ML-KEM in the slightest). So this is to say that there are natural "easier instances" of the thing underlying ML-KEM, and there still haven't been successful attacks of those instances. Anyway though, the question isn't "should you use pure ML-KEM rather than hybrid". I would personally suggest hybrid unless it is extremely limiting for some particular scenario (and there are scenarios, such as hardware, where it is). The question is "should we standardize how pure ML-KEM TLS works, so implementors can create interoperable implementations?". The answer to this should (clearly) be yes. ML-KEM is boring, high-quality cryptography. If a quantum computer appeared tomorrow, and only ML-KEM protected me, I would not lose any sleep personally. Efforts to delay standardization rely on "arguments" that do not match reality in the slightest.

JumpCrisscross 2mo ago

> Secret NSA documents showed that NSA pushed DES in the 1970s to "drive out competitors" while knowing that DES was "weak enough" to break; meanwhile NSA publicly claimed that it would use DES Is this true? The NSA pushed for weaker cryptography it could break versus stronger cryptography our adversaries couldn't?

tptacek 2mo ago
It's complicated. The federal government pushed for a smaller DES key size, but also fixed the DES s-boxes to resist differential cryptanalysis.
rurban 2mo ago
Sure. Everbody knows that
mswphd 2mo ago
as mentioned it's complicated, but the general trend of the NSA pushing cryptography they can break and others can't is well-known. https://en.wikipedia.org/wiki/NOBUS https://en.wikipedia.org/wiki/NOBUS note that there is no even candidate way the NSA would have a NOBUS-type vulnerability for ML-KEM. DUAL_EC_DRBG was known to plausibly have a NOBUS-style backdoor prior to standardization, provided you used a certain "default" generator (vs freshly generating your own). It was later discovered that the NSA payed RSA (the company) to do this. While this payment was private, the possibility of a back door was publicly known. There are no publicly known candidate backdoors for ML-KEM. The broad design of an ML-KEM-like scheme permits one ("static" matrix A), but ML-KEM was specifically designed to make this impossible ("ephemeral" matrix A).
philodeon 2mo ago
DJB wrote a short history of NSA’s malicious meddling in the cryptography we all use, based on a declassified internal history of the NSA. https://blog.cr.yp.to/20220805-nsa.html https://blog.cr.yp.to/20220805-nsa.html

tptacek 2mo ago

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____ 2mo 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.

jauntywundrkind 2mo ago

Is there anything different about this DJB mailing list brigading than the other brigading he's done? Four days ago: https://news.ycombinator.com/item?id=48760490 https://news.ycombinator.com/item?id=48760490

tptacek 2mo ago
By dint of not including a list of non-cryptographer cosigners, this one is prima facie somewhat less cringe.

iririririr 2mo ago

if i were the nsa, I'd have spent all my research money on attacking ecc+pq, because 1. no self respecting security engineer would deploy bare pq (see cloudflare), 2. no phd research team would attack the combination (well, not before until it's too late) because that's harder than a phd requires (they will target solo pq or solo ecc). 3. it's much easier to "sell". q.e.d. this article.

maqp 2mo ago
Probably not. It's been ~13 years when Snowden said what the NSA is doing is going around the encryption by hacking endpoints. Post quantum cryptography doesn't change any of that. You can still lift TLS keys with exploits for transparent MITM. I'd imagine it's much better ROI to look for vulnerabilities with Mythos, than to attack the algorithms.
- g-b-r 2mo ago
  > is going around the encryption by hacking endpoints Because they weren't (supposedly) able to break the encryption > than to attack the algorithms You have an opportunity to introduce new, broken, algorithms; they exploited it with DES, tried to exploit it with ECC, why wouldn't they try it with post-quantum (which they've kind of been pushing)?
  - maqp 2mo ago
    What's the vulnerability they injected into DES?
tptacek 2mo ago
This is completely backwards. The more cryptography-literate you are, the more likely it is you think hybrids are silly. Plenty of cryptographers think this is all bullshit, and that ECC+MLKEM makes about as much sense as an AES+Serpent cascade. It is simultaneously the case that MLKEM is far less mysterious than programmers on message boards think it is, and that conventional ECC and finite field cryptography is much more mysterious and spooky than they think it is. (I'm only somewhat cryptography-literate and so I would myself default to a hybrid, though that opinion might change the first time I bother banging together an MLKEM implementation.)

yardstick 2mo ago

DJB has orchestrated a vote rigging campaign against this WGLC, encouraging users to join the list and vote/express their opinion and providing the exact subject header to use. Have any other sides been saying, essentially, just join the group and say you’re for/against? He’s been moderated during the last call because of his email disclaimer/footnote, and apparently refuses to respond on list during this time. Seems like he’s playing a few steps ahead where he can (yet again) cry foul on the system and cry foul on vote rigging. Despite him being a key instigator. I’ve already seen at least one poster reference a RFC explaining how IETF consensus works and how its not a pure numbers game (5 for and 100 against can still be consensus, depending on the circumstances; the inverse also applies). What’s his next step if the authors publish as an information RFC? He can’t stop that, right?

eqvinox 2mo ago
> …information RFC? He can’t stop that, right? Informational RFCs still need to pass through the IETF consensus process, changing the intended status isn't a procedural bypass. However, the authors can just publish it elsewhere, it makes no difference at all for the codepoint allocations. Only distinction is that it doesn't get the somewhat intangible (but existent) "RFC sheen".
- ekr____ 2mo ago
  This document actually is being advanced as Informational, though there are also non-IETF Informational RFCs (see upthread).
ekr____ 2mo ago
> What’s his next step if the authors publish as an information RFC? He can’t stop that, right? This is a slightly complicated question. There are several main routes to an Informational RFC. * Through the IETF Stream, either through the Working Group (what is happening now) or via sponsorship by an Area Director. The former is what is happening now (this document is not up for Proposed Standard). I don't think the latter is likely to happen if TLS WG decides not to publish. If the TLS WG does decide to publish, then there are a number of steps afterward (AD review, IETF Last Call, IESG Review), plus potential avenues for appeal at some of these stages. * Through the Independent Submissions Editor (ISE) (though in another comment wbl says that the ISE is not going to publish cryptography standards https://news.ycombinator.com/item?id=48812844 https://news.ycombinator.com/item?id=48812844). This is essentially at the sole discretion of the ISE and can't be appealed. In either case, if the document makes it through all these gates and is eventually published as an RFC, then that's pretty much it, as RFCs aren't changed once published.

g-b-r 2mo ago

To those who say that approving or not this RFC won't make any difference: «- Liaisons: We received liaison statements from multiple SDOs including O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing support for the publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF to provide a stable normative reference» (https://mailarchive.ietf.org/arch/msg/tls/ol2otAvtdDrdz_xY0_eKcuY1om0 https://mailarchive.ietf.org/arch/msg/tls/ol2otAvtdDrdz_xY0_...)

slim 2mo ago

MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe As you know, teams are vulnerable to infiltration and individuals to compromise. Corruption often stems from various motives, including ideology

mswphd 2mo ago
that's really not possible for ML-KEM. They took a well-known "boring" design, and tweaked certain internal sub-components of it. Their tweaks were good, and their analysis/exposition of it were good. So they deserve to win. But there were many essentially identical schemes (e.g. Saber and New Hope are essentially the same as ML-KEM). To infiltrate/compromise ML-KEM, then NSA would need to do something like 1. corrupt some europeans for the literal submission, and 2. corrupt the competing submissions, which are substantially similar, and 3. corrupt the entirety of the cryptographic community so they miss a flaw in the (extremely simple tbh) 2011 paper htat kicked off hte design. If a conspiracy requires corrupting a single person it's plausible. ML-KEM being intentionally weakend by the NSA would quite literally require corrupting like 100+ different people in different countries. it makes no sense.

thomasdeleeuw 2mo ago

France and Germany propose hybrid schemes as well: The german position: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat... "The quantum-safe mechanisms recommended in this Technical Guideline are generally not yet trusted to the same extent as the established classical mechanisms, since they have not been as well studied with regard to side-channel resistance and implementation security. To ensure the long-term security of a key agreement, this Technical Guideline therefore recommends the use of a hybrid key agreement mechanism that combines a quantum-safe and a classical mechanism." The french position, also quoting the German position: https://cyber.gouv.fr/sites/default/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf https://cyber.gouv.fr/sites/default/files/document/follow_up... "As outlined in the previous position paper [1], ANSSI still strongly emphasizes the necessity of hybrid wherever post-quantum mitigation is needed both in the short and medium term. Indeed, even if the post-quantum algorithms have gained a lot of attention, they are still not mature enough to solely ensure the security"

tptacek 2mo ago
The IETF already has a standard hybrid scheme and it's what everybody already uses. That's not what this is about.

potatototoo99 2mo ago

If a US three letter agency recommends it, I don't want it.

some_furry 2mo ago
Didn't the FDA used to recommend pasteurizing milk?
mswphd 2mo ago
the NSA also recommends elliptic curve cryptography, and designed SHA2 themselves. if you want we can talk through how to disable all of these ciphersuites, so you can be stuck with a bunch of shitty stuff from the 90s and feel warm and fuzzy about it.