NSA and IETF: Fairness(blog.cr.yp.to) |
NSA and IETF: Fairness(blog.cr.yp.to) |
(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.
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.
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...
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".)
> Unfortunately, we can't yet say that about lattice cryptography, despite it being approximately as well-studied as ECC.
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.
I was happy to see the lead of Europe’s PQC team also voted with the cryptographers.
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...
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. :)
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?
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). 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.
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...
"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"
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...
Four days ago: https://news.ycombinator.com/item?id=48760490
Is this true? The NSA pushed for weaker cryptography it could break versus stronger cryptography our adversaries couldn't?
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).
«- 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_...)
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.)"
https://www.itu.int/en/ITU-T/tutorials/202203/Documents/Rein...
Apart from that, the crux of this is the codepoint allocation in the named group registry. [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.
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
MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe
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.
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)?
(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.)
You are if you're considering a cypher that's extremely likely to be secure.
In this case we're ok to introduce something with a chance to be quantum-resistant before it's been studied enough, because we want a chance of being quantum-resistant soon.
But that's only ok if you add it to the existing, reliable, systems.
Were there not the issue of quantum computers we wouldn't even be considering to use different cyphers at this time.
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".
Perhaps
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.
The inventor of the lobotomy won a Nobel Prize in Medicine for it.
Actually, Dr. Nadim Kobeissi formally proved that hybrid is secure, even if ML-KEM fails. [1]
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/), 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.
Yes, sorry, I was just covering against people nitpicking on the document status :)
The working group chairs have to decide if all of the objections have been "addressed". However, "addressed" doesn't mean "fixed via changes in the document", it can also mean "debunked on the mailing list" or "dismissed out of hand as irrelevant". So your argument that there obviously isn't consensus doesn't actually hold up.
Not "there's a 60/40 split, therefore there's no consensus".
Can be argued even in. That's a statement of allowance, not sufficiency. And I was speaking in the context of contrasting against a vote. You can't argue with a vote's tally.
Participants in disputes and RFCs literally call their comments “!vote” in true hacker notation, to repeatedly and clearly emphasize that “vote count” is never a factor in the process of establishing consensus.
(Elections are, however, regularly held, and votes counted, for positions such as Administrator, and the ArbCom seats, but that’s for people, not article content.)
Which is why I'm noting the alienation of "IETF believers", which I should maybe clarify I count myself as. The IETF is a lot of people doing a lot of good work. It does include a bunch of questionable actors, anything from ignorant, incompetent, ulterior motives, to outright malicious. But all in all it has brought us the internet as it exists today and I can't help feeling a little, well, alienated by DJB's writs.
[ed.:] https://blog.cr.yp.to/20251004-weakened.html#agreement says:
Anyway, IETF hasn't attempted to issue such a rule. On the contrary, IETF claims that WG decisions are not taken by voting: "Decisions within WGs, as with the broader IETF, are taken by 'rough consensus' and not by voting." This begs the question of what IETF thinks "rough consensus" means. Letting chairs make arbitrary decisions is a violation of due process.
More to the point, IETF can't override the definition of "consensus" in the law. That definition requires general agreement. Adoption of this draft was controversial, and didn't reach general agreement.
DJB making legal-ish arguments (or the idea that the IETF could be sued over a definition of "rough consensus") is absolutely inane to me. The choice of words of the IETF in defining its own processes for itself is not a legal one. And apart from that, which country's laws would that be? (I'm also quite skeptical about such a definition existing in a relevant manner to begin with.)
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...).
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.
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.
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.
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.
Maybe I said cypher for the AES+Serpent mention (and because I like cyberpunk xD)
I, too, don't support the IETF (hence the quote on the web page, which I can't find now). But I happen to know enough about the people involved in this particular drama that I can see through his arguments here, and whether he realizes it or not, he's operating in supremely bad faith this time.
I've met him in person, once, at a CCC event about a decade ago, and as someone clueless about cryptography all I can say to that is that he certainly had (has?) a my-way-or-the-highway personality.
> I, too, don't support the IETF
Out of curiosity, how would you maintain e.g. TLS? Something more academic? Raw "throw it all out there, best-wins"? Another SDO (e.g. ITU)? Other more formal international processes?
I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an opponent of all security and (especially) cryptographic standards bodies.
The gist of it is that standards organizations like the IETF depend on a specific carve-out in US antitrust law (in order for it to be legal for American companies like Cisco and Google to participate in them), and that carve-out includes a specific definition of what "standards organizations" and "consensus" are. So even if the IETF uses different words to describe its processes, those processes still have to comply with the legal definition that separates a "standards organization" from, like, an illegal cartel.
* the IETF's approach predates 15 U.S.C. §4302 by more than a decade
* every single case example cited is US-American scoped¹ SDOs: American Society of Mechanical Engineers, National Fire Protection Association, American National Standards Institute²
¹ NB scope ≠ legal domicile. The IETF's legal status is… complicated… but does have US dependencies. Its scope is world-wide though. Not so for any of the mentioned entities, even if…
² …ANSI is a borderline case since it is the constituent ISO member. But still, it's the US entity.
I'm not trying to make a legal argument here, but… I'll say he shouldn't be trying to do that either. Most mathematicians and CS majors make very poor lawyers in any case, and often enough without any awareness of 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.
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.
having said that, I would trust McEliece more than Kyber.
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.
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.
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.
Besides, I don't doubt the US spelling has taken over, that has happened a lot in a wide range of fields, but it doesn't invalidate the British spelling, even if it isn't as widely used in recent published papers.
It's like claiming that the element is sulfur not sulphur, because papers are increasingly written for an international audience. In British English, the element is Sulphur, regardless of whether you can find an "important paper" using the spelling.
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.
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.
Cryptographers can be good, bad, be more or less knowledgeable about applied cryptography, and possibly have agendas.
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...
Somehow I wouldn't trust my data on mathematical problems, for which the recommendation is that they would challenge Kayne West.
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.
1. algebraic structure: sure use frodoKEM
2. error rates smaller than those required for worst-case to average-case reductions: idk bump error rates
3. some coding theorist ruins everyone's fun and has linear time decoding for p-ary construction A codes: probably drink a lot idk
fortunately there haven't been any "incremental" attacks in any of these directions, so it is really more an academic discussion.
Also note the primary issue with FrodoKEM isn't performance (though that is definitely worse), but size. My impression from the following
https://blog.cloudflare.com/sizing-up-post-quantum-signature...
https://blog.cloudflare.com/making-protocols-post-quantum/
was that TLS w/ FrodoKEM might have some undesirable performance characteristics, though that isn't directly stated in the articles. Iirc TLS w/ FrodoKEM
This is in fact that what I meant, and should have said: thanks.
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.
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.
“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.
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...
* 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..
Hmm. This doesn't entirely connect for me… WireGuard and OpenSSH are first and foremost implementations. Are you implying people should follow a "primary" implementation? Does WireGuard even have a protocol specification? (searches - ah, yes, it does. I do know there have been a very number of "further" implementations [e.g. on FreeBSD], though I'm not sure if they're derivative or clean-room.)
But then isn't this just replacing IETF processes with whatever community or corporate processes those projects have? Wouldn't that just be "get shit into {the Linux kernel,OpenBSD}"? They've gotten better but both of those communities have their shortcomings. (For Linux, it's not the social interactions anymore, at this point it's the significant corporate interests.)
The problem with cryptographic standards bodies is that committee-based design has a long track record of weakening protocols. Originally, part of the ethos of the IETF was that it was merely providing interop for things that were already happening; rough consensus around real implementations. But that attitude expired decades ago; things are now designed de novo in working groups.
Through a herculean effort, TLS-WG managed through that fucked process to drastically improve TLS in 1.3. It did that in part because a team of cryptographers and cryptography engineers camped on the working group and made sure the outcome was sane. And they nearly failed! Banks fought hard to try to keep static handshakes in the new version, so they could do compliance intercepts.
Unfortunately, fully documenting PQC cryptography isn't as glamorous a task as defining the next generation's version of TLS. And yet, we've got a somewhat diverse team of cryptographers on the working group lined up against Bernstein on this.
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).
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.
One very big problem I have with Bernstein's recent activism is the way he writes to an audience you can just very clearly tell he thinks little of. He's assuming everybody who pays attention to this stuff has paid basically no attention at all to any cryptography he himself didn't write about. It's a bad argument, but that's not my big issue; my big issue is that he's making fools of his supporters. Not OK.
"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."
(I had the pleasure of shipping a commercial product, back in the days when those things shipped in shrink-wrapped boxes, that carried strong cryptography, and had to deal with the export regime. It was not fun.)
This was still a very bad policy, but private americans were allowed to have strong cryptography.
I wrote at length about this debate in my blog post about threat modeling: https://soatok.blog/2026/06/30/soatoks-informal-guide-to-thr...
* 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:
WRT IPv4 NAT, I'm not sure how much we can infer from the status. Many people at IETF were (and some still are) very anti-NAT, in part because they felt that IPv6 was the right solution. As a result, the IETF really avoided doing anything that looked like it was endorsing NAT, even though it's obviously just a fact of the Internet.
(If my subtext wasn't clear, by the way: the implementation history of ECC is godawful.)
> the implementation history of ECC is godawful
You do know that new cryptographic code can be godawful, then?
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
The draft only specifies the MLKEM binding into TLS; it'd be out of scope for it to go into detail on implementation considerations for MLKEM. Those would belong in or adjacent to FIPS 203 (the actual MLKEM specification).
> It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]
It's actually RFC8032 that this criticism would apply to, since it is actually specifying EdDSA, not just referencing it externally.
FIPS 203 doesn't care about side channel resistance, per my other comment at [1]. And this draft doesn't do anything to tighten the constraints on how FIPS 203 should be implemented to provide side channel resistance.
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.
Incentives are basically all I consider when trying to establish true motive. But you're not required to consider motive when there's a history or pattern. Even if "It's the way we've always done it", wasn't a much, much stronger motive than thought/reason is for any human. It's both logical and desired to treat something as the most dangerous until proven otherwise.
I used to be a nurse. I remember when working in the ED, I was taught that every single woman on childbearing age who comes into the ED with abdominal pain is an extopic pregnancy until proven otherwise. If you ask a woman if it's possible she could be pregnant, regardless of the truth, many will claim it's impossible. If you blindly trust them, and delay treatment, you could needlessly kill your patient, or leave them infertile. Why would someone lie and risk that? Or how dare your medical team make assumptions like that? Well the alternative is worse, the reality should be easy to prove.
NIST has a history of recommending broken ciphers. That's not a mistake a professional would ever make. So thinking about incentives, I'm going to treat it like it was intentional. Here the group with a history for fucking up, isn't being transparent. I would love it if NIST would say enough to make DJB happy or at least stop pretending like they deserve any trust anymore.
Until then, I don't find "they're probably behaving like rational actors" compelling enough to trust them with keeping secrets from somebody who I actually do trust.
Incorrect. My argument is that they aren't the same entity.
The thing you said is a whole different argument. "I like waffles" "So you hate pancakes" is happening.
> Incentives are basically all I consider when trying to establish true motive. But you're not required to consider motive when there's a history or pattern.
Yes you are. You need to consider both factors. Why render yourself willfully ignorant? That's not how you arrive at truth.
"Weaknesses in the cryptographic security of the algorithm were known and publicly criticised well before the algorithm became part of a formal standard endorsed by the ANSI, ISO, and formerly by the National Institute of Standards and Technology (NIST). One of the weaknesses publicly identified was the potential of the algorithm to harbour a cryptographic backdoor advantageous to those who know about it—the United States government's National Security Agency (NSA)—and no one else. In 2013, The New York Times reported that documents in their possession but never released to the public "appear to confirm" that the backdoor was real, and had been deliberately inserted by the NSA as part of its Bullrun decryption program."
https://en.wikipedia.org/wiki/Dual_EC_DRBG
"NSA worked closely with IBM to strengthen the algorithm against all except brute-force attacks and to strengthen substitution tables, called S-boxes. Conversely, NSA tried to convince IBM to reduce the length of the key from 64 to 48 bits. Ultimately they compromised on a 56-bit key"
https://en.wikipedia.org/wiki/Data_Encryption_Standard
The NSA published algorithms are not used for the important US secrets. For these system the classified algorithms of NSA Suite A are used.
https://en.wikipedia.org/wiki/NSA_Suite_A_Cryptography
NSA Suite A was probably used for Space Shuttle comunication. NASA scrambled to recover classified communications gear after the Challenger shuttle disaster in 1986.
https://www.globalsecurity.org/org/news/2003/030206-comsec-s...
They made DES more secure against differential cryptanalysis (a method that was classified at the time DES was being designed). Sure, the whole "make the keys 56-bit instead of 64-bit" is a weakening, but differential cryptanalysis would have broken the entire fucking cipher if they didn't prevent it by selecting a secure S-box.
> The NSA pushed backdoored design of Dual_EC_DRBG was standardized in NIST SP 800-90A.
Correct, which another threat actor used in a backdoor by replacing the public key.
I'm not arguing that NIST isn't vulnerable to NSA influence. I'm arguing that they are not the same entity and do not have the same goals or incentives.
I'm not an NSA defender. https://furry.engineer/@soatok/116854899284071513
The controversy over the PQC is the topic at hand. If they'd selected a cipher that didn't carry the objections of someone who's reputation I trust more than NIST. Then I'd trust NIST's decision, by proxy.
That's what's so crazymaking about this. People who actually pay attention to cryptography know all this, so much so that Bernstein sounds deranged to many of them. But he's counting on you not knowing any of it. Which is to say: he's preying on your ignorance. It's a bad scene.
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?
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
But draft-ietf-tls-mlkem just handballs to FIPS 203 for description of cryptographic primitives, and FIPS 203 doesn't care about side channel resistance. The token reference to NIST SP 800-227 for how to securely implement MLKEM also offers no suggestions on side channel resistance.
The draft MLKEM IKEv2 RFC[2] has the same problem.
Which standard, if not draft-ietf-tls-mlkem, changes the draft-ietf-tls-mlkem specification of the following cryptographic primitive:
Original: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret."
To include side channel resistance, for example:
Improved: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret. Decaps() MUST be implemented as a constant time function to ensure the time needed to execute Decaps() does not differ for different sk and ct values."
Some further examples of RFCs which do care about specifying side channel resistance:
RFC 9980 (OpenPGP PQC) s9.3: "This specification makes use of the default "hedged" variants of ML-DSA and SLH-DSA, which mix fresh randomness into the respective signature-generation algorithm's internal hashing step. This has the advantage of an enhanced side-channel resistance of the signature operations according to [FIPS-204] and [FIPS-205]."[3]
RFC 9941 (SSH sntrup761x25519-sha512) s4: "As discussed in the security considerations of [RFC8731], the X25519 shared secret K is bignum-encoded in that document, and this raises the potential for a side-channel attack that could leak one bit of the secret due to the different length of the bignum sign pad. This document resolves that problem by using string encoding instead of bignum encoding."[4]
(this RFC 9941 example has the benefit of showing how draft-ietf-tls-mlkem could take problematic cryptographic primitives from FIPS 203 and tighten the specification within an RFC to enforce side channel resistance)
[1] https://www.rfc-editor.org/info/rfc8446/#appendix-E.4
[2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-ml...
"
Michael Hayden, a former NSA Director, has since acknowledged the concept of NOBUS:
You look at a vulnerability through a different lens if even with the vulnerability it requires substantial computational power or substantial other attributes and you have to make the judgment who else can do this? If there's a vulnerability here that weakens encryption but you still need four acres of Cray computers in the basement in order to work it you kind of think "NOBUS" and that's a vulnerability we are not ethically or legally compelled to try to patch – it's one that ethically and legally we could try to exploit in order to keep Americans safe from others."
In general we can asume that NOBUS applies to everything NSA publishes or supports. If not in direct algorithmic weakness, then in weakened parameters or in selection of algorithms that are hard to implement in secure way without specialized hardware support (side channel attacks of AES, sensitivity of DSA to quality of random number generator, hard to correctly implement NIST curves - generated by NSA).
Your mind is going to be blown when you learn about proxy organizations and cut-outs.
Would you indict NIST MEP https://www.nist.gov/mep/about-nist-mep as being an NSA project without evidence?
Did I claim they were the same?
> The thing you said is a whole different argument. "I like waffles" "So you hate pancakes" is happening.
uh.... you started it? What are we even doing? I'm not above this kinda comment, but I kinda assumed you were? I'd be interested if you have a take I haven't considered; but not if we're just going to try to make straw man of the other.
> Yes you are. [required to consider motive]. Why render yourself willfully ignorant? That's not how you arrive at truth.
I'm not looking for a pure truth. I'm just looking for a heuristic that's just functional enough to keep me, and my data safe. I don't even want to make a perfect is the enemy of good argument. I'm just pointing out, where my line is. I lack the maths knowledge, practical experience, fucks left to give, and spoons remaining for the things I want to spend my time one. Evaluating every bit of information I could possibly gather, and witholding and judgement is a cute idea, but I've got better things to do. NIST has in tandem with the NSA, lied, and shipped a broken crypto system. Let's pretend I don't consider that to be permanently disqualifying, resign, stand up a completely new group from scratch, black tag/non-salvageable. They've burned the default good will everyone starts with, and then peed on it for good measure. Now they're hiding information AGAIN?!
Nah, I could waste my time trying to find the objective truth. Or I could give NIST the finger, and say, make the person with the remaining good will and trust and fucks left to spend on NIST happy. Only then come back to me. Until then, I refuse, and for the same reason I refuse to review LLM PRs; I'm trying to do things, and [they] are trying to DoS my brain.
Ideally, you'd stop helping [the them], or answer the remaining objections line by line, and publicly? Then I'd have someone else with enough good will that I can trust. Because NIST is doing the opposite if they want my confidence.
I know all of that, I also know I'm years away from the maths to understand the crypto and decide for myself. So, I'm forced to have an opinion because friends and employers will expect me to have one; like them, I'm also forced to operate on trust. Help me with this one? Because my problem is, the only person in the whole scene with ethos is djb. Not a single person in the stack has their name on *anything* that would allow me to trust them given their previous behavior.
So who's the non-deranged person that can put their ego aside, long enough to go point by point down the "deranged man"'s "psychotic rant". Where something everyone who's paying attention can point to and say, djb has stopped taking his crazy pills, here's what reality looks like. Because I went looking for it when I first heard about it, his blog has been linked to from HN many times. But no one has linked to a single other person. I agree with you, the arguments he's making are barely convincing. But one one side, I have a well respected cryptographer (who might want to consider or respond to the accusations he's becoming a bit eccentric) saying hey, y'all are fucking it up. Directly to the people who actively did something ethically inexcusable. Who not only appear to following the exact same pattern as last time, but no one is willing to put their name and time on the line?
What am I supposed to do? Get on board because NIST recommended it already, and there's the RFC for it, so why bother fighting? Just trust the current or next US administration won't do something I object to... like trying to back door crypto... again... I know you'd never actually make that recommendation... well I hope at least. But really; what would you expect me, someone who still trust djb even though his eccentric writing is desperate for an editor, and also, someone who actively believes the people in charge of NIST are ethically questionable. What should I do? where's the evidence that would convince me to switch from believing the guy working to improve foss crypto, to the org with a history of delivering backdoor'd crypto.
The problem here is that literally the only information you have to work with is Daniel Bernstein, a notorious standards crank. The names of the cryptographers vouching for Kyber don't mean anything to you. Peter Schwabe? Leo Ducas? Chris Peikert? You're not a cryptographer, who could reasonably expect you to know who those people are?
And Bernstein knows it, and plays it to the hilt.
But I already pointed this out. You keep bringing it back to NIST, but I keep telling you: if you simply let a panel of PQC contestants with credible affiliations vote on it, you'd have gotten the same outcome. So we're really just going around in circles here.
I'm not taken in by the crazyness on either side, and while if pressed, it's obvious which side I would pick. I'm not so much picking a side, so much as complaining again, how we're letting a group with an earned reputation for being untrustworthy keep secrets about crypto. I hate the whole thing, but that's how little trust I have left in other people. The crazy guy is the on the side I hate less... but what to do?
edit:
> You're making my point for me. Nobody in the whole world is asking for you to take NIST's word for anything.
Literally everyone standardizing on Kyber is asking me to trust NIST, et al, and pay the additional overhead for setting up a TLS connection. I guess you could frame it as they're not asking, because I'm not being physically forced to interact with them... but then I try really hard not to engage with bad faith bait, when I'm able to resist.
If I see another computer offer TLS named group 0x0200 (MLKEM512) as introduced by draft-ietf-tls-mlkem, do I have any assurance that the other end I'm communicating with uses constant-time Decaps(sk, ct)?
--
The answer as far as I have presented is NO. TLS named group 0x0200 (MLKEM512) is free to be used for leaky MLKEM implementations that have made no effort to be side channel resistant. The end state for MLKEM-only will be the IANA registry stating TLS named group 0x200 (MLKEM512) is specified in RFCxxxx (draft-ietf-tls-mlkem), and this RFC will refer to FIPS 203 for cryptographic primitives. At no time is side channel resistance in any way guaranteed by either draft-ietf-tls-mlkem or FIPS 203.
The situation for TLS named group 0x0029 (x25519) is different. The IANA registry nominates RFC 8446 as the relevant specification.[1] And RFC 8446 nominates a specification (RFC 7748) which does require implementation of cswap as a measure of side channel resistance.[2][3] So when you trace through the specifications starting from the IANA registry, it is unambiguous that TLS named group 0x0029 should provide at least some degree of side channel resistance. Even for this case, I'd argue the SHOULD would be better as a MUST (with possibility to add another TLS named group specifically for x25519-unsafe without constant-time cswap if anyone cares for it). And I'd also argue that RFC 8446/TLSv1.3 should require (not just suggest or hope) that implementations MUST only use constant time functions when processing ECDHE parameters per s4.2.8.2.[2] TSLv1.3 already requires AEAD use elsewhere to force constant-time processing. It's worth noting TLSv1.3 currently doesn't provide any guarantee about side channel resistance of secp256r1, secp384r1, and secp521r1. TLSv1.3 currently just provides this guarantee for X25519 and X448.
[1] https://www.iana.org/assignments/tls-parameters/tls-paramete...
[2] https://www.rfc-editor.org/info/rfc8446/#section-4.2.8.2
That's beyond moving goalposts. Just take the L, dude.
Just because NIST engages in some wholesome activities doesn’t mean that their core purpose isn’t to do the bidding of the NSA.
Their core purpose is to recommend standards that everyone can use, and anyone who wants to work with the US government is expected to follow. They have to pick standards for everything, but can't have experts in everything on staff, so are required to defer to other experts willing to help. The NSA took advantage of them. I find the idea that NIST wants to be a lackey to the NSA, stupid. It's ignorance and incompetence that lead NIST to getting duped by the NSA. The problem is, not getting dupe is literally, their *only* job.
It's like hiring a firefighter to protect you and then they set your house on fire; it doesn't matter so much why you don't have a house anymore... you just sure a hell are never letting him near anything important every again.
You're allowed to treat gross incompetence as equivalent to intentional malice, without needing to make something up about how it was intentional.
> you don't have to trust the server
oh, sorry I should have realized this wasn't a conversation anymore
Good luck buddy :)