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.
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.)"
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".
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.]
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/), 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.
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.
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.
Sadly, a similar myth/fallacy persists about the Wikipedia consensus process (at least the English project and others deriving policy from it.)
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.)
There is a small and noisy contingent here that never fails to get bent about community driven projects accusing them of bias and insinuating that there is some kind of shadowy cabal running things and it would be hilarious if the reasons for it weren’t so transparent. Also those people are 100 percent MAGA
From the way DJB talks about IETF processes, it's quite clear to me though that he has little trust/belief in the IETF consensus process. I thought he said as much somewhere but can't find that right now. (It's particularly obvious in https://blog.cr.yp.to/20260405-votes.html)
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.
He famously doesn't support the IETF. In the long-long-long ago, back when I had a "home page" with my username and a tilde in it, I used to have a quote from him on it about the IETF and "ego standards". He's been picking fights like this with different IETF working groups for basically his entire career. This isn't even the first time he's picked a huge fight with IETF cryptography groups; he managed to get Kenny Paterson to publicly take him to task on the CFRG a few years back.
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.
> 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?
* the IETF's procedures predate 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.
The issue with saying that "there's a 60/40 split, therefore there's no consensus" is that the IETF explicitly documents that that isn't the case: RFC 7282, Section 7, "Five people for and one hundred people against might still be rough consensus" (https://datatracker.ietf.org/doc/html/rfc7282#section-7).
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.
What I said was "It makes much more sense to argue there is no consensus […] can be argued even in a "60:40" situation regardless of direction".
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.
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...
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.
> 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 inventor of the lobotomy won a Nobel Prize in Medicine for it.
> 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?
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).
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.
> (2) The RFC at issue documents the possibility of running TLS with pure MLKEM rather than in a hybrid configuration with ECDH. Hybrid TLS is already the mainstream, documented, standardized method for using PQC in a TLS connection. Bernstein is canvassing opposition to any documentation of the possibility of pure MLKEM in TLS.
Two more pieces of context here:
1. The IETF allows code point registrations based purely on the existence of a specification, and the pure ML-KEM code points have already been assigned (https://www.iana.org/assignments/tls-parameters/tls-paramete...). The question at hand is whether the IETF will publish an RFC documenting the ML-KEM.
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).
> there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document
“People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t.
(There are counter-arguments as well, of course. A couple of relevant cases that spring to mind where a body has not aligned with usage or expectations: W3C lost control of HTML, and it was probably for the best, but they remain a relevant body in closely-related areas; and OSI licence approval is a horribly broken political process which is almost universally misunderstood and close to frozen in time, yet they haven’t suffered like they should have for their misdeeds, they pretty much got away with it. There was also that thing somewhat recently about FedRAMP rubber-stamping Microsoft Cloud despite it failing dismally, because US government agencies had already started using it too much; and I wonder what that does to their credibility.)
This is also a concern with informational/independent submissions through IETF. They are frequently perceived as having IETF/standards weight.
> “People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t.
The GOST cipher, which is Russia's AES equivalent, is also in an RFC:
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):
In fairness, I do think that this situation is somewhat different. As I noted above (https://news.ycombinator.com/item?id=48812792), there are two main routes to an Informational RFC of this kind.
* Through the IETF
* Through the Independent Stream
The GOST documents went through the Independent Stream and therefore do not have IETF imprimateur. These documents are proposed for the IETF Stream and therefore require IETF Consensus to publish.
I know this is all super confusing. The basic problem is that the vast majority of RFCs come out of the IETF and so people often act as if all RFCs do. This is of course in part why people pursue Independent Stream publication rather than just publishing things on their own..
I have gotten flack for giving ULA+NPTv6 as a possible solution to an IPv6 multi-homing issue because the RFC that describes it was 'only' "Experimental":
I have no opinion on ULA+NPTv6, other than Experimental doesn't mean you shouldn't use it. How else would people experiment. It does mean that the level of vetting by the IETF is potentially lower.
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.
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.
In the 90s, you as a private person were not supposed to have access to encyption which could not be broken by NSA.
"The longest key size allowed for export without individual license proceedings was 40 bits, so Netscape developed two versions of its web browser. The "U.S. edition" had the full 128-bit strength. The "International Edition" had its effective key length reduced to 40 bits by revealing 88 bits of the key in the SSL protocol."
note that this says something more limited than what you're saying. Specifically, an american company was not allowed to give access to the cryptography you describe to non-Americans.
This was still a very bad policy, but private americans were allowed to have strong cryptography.
No. In the 1990s, you weren't allowed to export cryptography the NSA couldn't break. Strong cryptography was widely available in the 1990s.
(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.)
To point out some positive examples of what RFCs should include:
RFC 5288 s3 (AES-GCM): "Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security."[1]
RFC 7748 s5 (X25519): "The cswap function SHOULD be implemented in constant time (i.e., independent of the swap argument)."[2]
By contrast, this proposed RFC for MLKEM provides a single encouragement:
"[NIST-SP-800-227] includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."[3]
It's not even a SHOULD, it's just an encouragement in a non-normative section of the RFC.
When you go to the referred NIST SP 800-227 it then tells you it's all too hard anyway and good luck and have fun figuring it out yourself:
"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."[4]
The normative standard FIPS 203[5] which the draft MLKEM RFC relies upon NEVER mentions "side channel", "constant", "timing" or provides any other assistance to implementers on how to securely multiply and/or divide numbers on computers or how to deal with conditional branching. Fair enough it includes a lower case "should" for considering side-channel resistance, but this throwaway comment is inadequate for standardisation.
The main reason it is inadequate is, imagine you're on your Hardened Gentoo or some other uber-geek laptop with the most advanced and thoroughly tested side channel resistant MLKEM client imaginable. You want to access your bank's website that offers MLKEM-only TLS. You don't have any assurance the bank's implementation of MLKEM has implemented any side channel resistance because the RFC they claim to have implemented never required it. If you then extrapolate from historical woes of implementing side channel resistant crypto (ECDSA scalar multiplication for example), it's probably correct to assume someone has, or reasonably could at some point in the future, extract private keys from the bank's side, and thus your expectations of having a secure connection are unmet. This is a standardisation problem because two implementations cannot agree on whether the protocol offers any resistance to side channel leakage to remote adversaries, therefore, what is the security guarantee the two implementations can actually agree upon?
The key missing section of this RFC is perhaps a restriction on its application similar to:
"This standard does not require implementations to consider side-channel attacks. This standard SHOULD NOT be used for protecting data and communications where an adversary may have one or more of: a) physical access to equipment performing cryptographic operations and time and resources necessary to observe physical properties of the equipment (power and signal characteristics, electromagnetic radiation, thermal dissipation), b) ability to execute code on equipment performing cryptographic operations, c) remote access to high-resolution monitoring data of physical properties of equipment performing cryptographic operations, d) ability to observe and/or establish a session to a party using this cryptographic protocol."
Thus it'd only be applicable to low risk environments such as two servers in a government building in separate rooms where an adversary is prevented from conducting a side channel attack by a plethora of other security controls.
You are confused about what this RFC is. It's not the enabling RFC for PQC in TLS, or for MLKEM. It's documentation about a specific set of parameters for doing pure, as opposed to hybrid, MLKEM. It defers the guidance you're looking for to other RFCs.
From RFC8446 (TLSv1.3) sE.4: "In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives."[1]
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)
Sir, this is a Wendy's. You're giving me a phone book's worth of RFC cites here but not a lot of indication that you spend a lot of time reading RFCs generally. The RFC we're discussing on this thread is an ancillary publication documenting code points for a specific configuration of MLKEM, which is already extensively documented in other RFCs. Ancillary RFCs like these are for obvious reasons brief.
My key point you are avoiding with personal attacks is:
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.
using pure ML-KEM is not a footgun. Some people may have doubts about lattice-based cryptography, despite being securely deployed in Chrome nearly a decade ago. Some people have doubts about many things. The fact that people have doubts does not make the scheme a "footgun".
you'd probably call it "Product NTRU" then, and be a minimum a decade out of date. So you'd probably have to do all that weird shit with co-different ideals Peikert was trying to get us all to do (I know it was "right" but sometimes you need to put a muzzle on the math guys for all of our sakes).
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.
He's a cryptographer. You're describing cryptographers. You get that other cryptographers designed Kyber/MLKEM, and still more implemented it, right? There are cryptographers besides Daniel J. Bernstein.
I, for one, wouldn't care if Kanye West or his aunt or her neigbours dog came up with a good encryption algo. If it's good, it's good no matter who wrote it. Appeals to authority or the lack thereof draws attention away from the technical debate.
Unfortunately, that's not how modern crypto works. Many mathematical problems on which algorithm rests their security are not proven to be unsolvable, but instead they're believed to be hard to solve. So here are the questions, who believes what is hard, and hard for whom.
Somehow I wouldn't trust my data on mathematical problems, for which the recommendation is that they would challenge Kayne West.
Not all cryptographers (and cryptography standards) care about real world implementation, or have the same use cases in mind for their cryptography algorithms and protocols. For example, almost every cryptography standard in common use treats side channel resistance as an optional after-thought for implementers. This might be fine for some users, for example, the US government, because they generally don't implement cryptography on systems an attacker would have physical access to, and don't use cryptography protocols on public networks. For these users, having maximum performance at the expense of side channel resistance might be the best trade-off to make.
For most users however, side channel resistance is a very important property that shouldn't be considered an optional after-thought. If standards bodies made it mandatory to consider side channel resistance when standardising cryptography schemes, the choice of what scheme(s) to standardise could look quite different, and thus general use of cryptography would have improved security by default. If some types of users don't care about side channel resistance, then great, make use of non-side-channel-resistant cryptography optional for them to use. Don't standardise it the other way around.
For example:
FIPS 186-5 sB.1 states: "Other (constant time) algorithms that produce an equivalent result may be used."[1]
NIST SP 800-186 sE.4 states: "If one is concerned about side-channel leakage, one should compute the inverse using a constant-time algorithm."[2]
RFC 8032 s8.1 states: "Note that the example implementations in this document do not attempt to be side-channel silent."[3]
A better standard may, for example, _require_ [4] be implemented in order for an implementation to claim conformance with the standard. Not as an optional after-thought. If there are users wanting to trade off side channel resistance for performance gains, then write a new standard to that effect and remove the requirement to implement [4].
A better standardisation process may, for example, only accept candidate algorithms _if_ they are side channel resistant. This opens up the standard to as many use cases as possible. No cutting corners to pretend performance is better for one implementation because it trades off side channel resistance for performance, and no pretending side channel sensitive use cases don't exist.
No, it's not an absurd claim. Lattice key establishment goes back into the mid-1990s, and was at one point a serious contender for the alternative-to-RSA/FFDH algorithm that ECC became. Modern LWE lattice KEM is approximately at the same point in its lifecycle (say, compared to original NTRU) as Curve25519 was to ECDH.
It does not matter much how long it goes back, because before its standardization very few people have bothered to study it.
Like for any other cryptographic algorithms, where one or more decades were necessary for a good understanding of their properties, we can expect much more relevant publications about lattice key establishment in the next years, than until now.
this is entirely wrong. Lattice-based cryptography has been extremely well-studied theoretically and practically, even before standardization. For example, a (hybrid) lattice-based KEM was (experimentally) deployed in Chrome in 2016.
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.
You are simplifying ad absurdum. The NSA is as likely to compromise hash and signing algorithms as the police are likely to recommend pissing in petri dishes to cast doubt on that troublesome forensic science. The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber. Estimates at one point were that they had more than half of appropriate PhD level Mathematicians in the US, that may have gone down with more cryptocurrency firms, etc, but those firms are not researching algorithm families that may or may not replace the standards with all that much interest.
It means that your argument is “the NSA couldn’t have subverted ML-KEM, it was written by Europeans”.
You assiduously pretend that this scenario isn’t possible:
* The NSA reviewed the PQ submissions and realized that there’s one they already know how to break at scale: ML-KEM, because their army of math PhDs spent a couple decades understanding it better than the rest of the world
* The NSA decides they want ML-KEM deployed everywhere so that the world is full of transparent-to-NOBUS cryptography
* The NSA spends the entire PQ contest placing their thumbs on the scale of the process, violating their 2014 post-Snowden promises of increased transparency, to make their NOBUS dreams happen
The actions of NSA and NIST personnel make the most sense with the assumption that they desperately want to standardize ML-KEM and ML-KEM alone because _they already know how to break it_. What doesn’t make any sense is why the private sector is cheerfully going along with it —- even Charlie stopped letting Lucy hold the football at some point.
You're just restating the same claim with more words. It obviously proves too much. You can stick any algorithm, from MLKEM to SNTRUP to CRC32, in the same comments and get the same result.
I certainly find it fascinating that the majority of those in favor come from signal intelligence agencies, while the majority of those against are PhD cryptographers.
I was happy to see the lead of Europe’s PQC team also voted with the cryptographers.
I might have expected you'd be once bitten twice shy after having once taking an aggressive position that DUAL-EC would never have backdoored anyone in practice...
The optionality of MLKEM by itself is of a similar shape to standardizing a lame DRBG that 'obviously' no one would use and anyone who would use would use the appendix parameter generation scheme that would have rendered it secure (although still slow). The reality of it was that once it was standardized NSA was able to secretly compel it's use.
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 strenghtening direction...) it's possible that their influence was motivated by things like that ease of undetectable compromising specific imlementations through techniques like dopant adulteration or specialized side channel weaknesses.
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 justifies the utmost concern and caution.
None of this makes any sense once you understand that NSA had no hand in designing MLKEM, or in shaping the LWE research that led to it. NSA designed Dual-EC. MLKEM won an open competition; its entrants are among the most reputable cryptographers in the world.
it's worth clarifying that its entrants were all qualified, and 2 other essentially identical schemes, namely New Hope and Saber, made it very deep into the NIST competition.
All 3 (roughly) took the approach of
1. take the obvious best design, and
2. tweak various internal design knobs you have access to, and
3. that's pretty much it.
So they differ in the internal design knobs they chose. But the fact that 3 independent teams all created something substantially similar to ML-KEM should be an indication of how much harder it would be for the NSA to be behind it.
You’re being rude, which wouldn’t be good even if you weren’t wrong on all three counts. This is not contriving positively.
(Consider the difference between extensive peer-review and “appeal to authority”, not to mention the IETF’s dual role encouraging research along with mainstream deployments)
They didn’t get MLKEM deployed by saying “I’m a professor of computer science at $UNI, do it!” but by working within the community for many years and going through an elaborate review and standardization process with extensive peer review and public comment. That’s not infallible but it’s misleading to talk about it as if it’s the same as the U.S. federal government (a real capital-A authority) mandating it.
This matters because academic reputation is so important in the field: none of these people can force even their own universities to adopt something and if you say they pushed something through covertly you’re making a really serious claim about a core professional trait which reflects not only on them but also many of their colleagues who reviewed and supported that proposal, and that should have evidence that this was bulled through rather than simply asserting it.
Correct. The argument is not about the deployment or the technical quality of MLKEM. Pretending it is, is an appeal to authority, and is moving the goal posts from the actual argument.
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.
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.
> is going around the encryption by hacking endpoints
Because they weren't (supposedly) able to break the encryption
But w
> 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)?
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.
(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.)
> The more cryptography-literate you are, the more likely it is you think hybrids are silly
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.
Exercise for the reader (out of genuine interest): find the most important cryptographic paper published in the last 15 years that uses the British spelling.
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 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.
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?
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".
> 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.
Thanks for the clarification. It’s a bit of a shame as going via ISE would have let the group move onto other endeavours. Maybe people will just refer to the draft name and that’s that.
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»
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
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.
"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:
"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"
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.
110 comments
[ 3.1 ms ] story [ 63.9 ms ] threadIf 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:
[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.]
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 :)
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.
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.
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?
* the IETF's procedures predate 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.
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.
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...
Perhaps
https://blog.cr.yp.to/20260704-bugs.html#damage
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.
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).
https://blog.cr.yp.to/20220805-nsa.html
(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.
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...
“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..
* https://datatracker.ietf.org/doc/html/rfc6296
When I pointed out that the NAT(44) RFC (1631/3022) was 'only' "Informational" I got radio silence:
* https://datatracker.ietf.org/doc/html/rfc1631
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.
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.
"The longest key size allowed for export without individual license proceedings was 40 bits, so Netscape developed two versions of its web browser. The "U.S. edition" had the full 128-bit strength. The "International Edition" had its effective key length reduced to 40 bits by revealing 88 bits of the key in the SSL protocol."
https://en.wikipedia.org/wiki/Crypto_Wars
This was still a very bad policy, but private americans were allowed to have strong cryptography.
(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.)
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]
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...
[3] https://www.rfc-editor.org/info/rfc9980/#section-9.3
[4] https://www.rfc-editor.org/info/rfc9941/#section-4
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
[3] https://www.rfc-editor.org/info/rfc7748/#section-5
DJB is not just a mathematician looking over theoretical equations. He's also an expert in the real world _implementation_ of cryptography where most security failures can be expected to occur.
For some mathematician's brilliant cryptography scheme, how easy would it be for implementers to develop constant time / constant power computer algorithms to avoid side channel leakage? Have these computer algorithms been developed, are they easy to implement securely or are implementers going to continually mess it up?
See [1] and [2] for answers. Summary: Technology is not ready.
[1] https://dl.acm.org/doi/10.1145/3569420
[2] https://dl.acm.org/doi/10.1145/3779208.3785290
Cryptographers can be good, bad, be more or less knowledgeable about applied cryptography, and possibly have agendas.
Somehow I wouldn't trust my data on mathematical problems, for which the recommendation is that they would challenge Kayne West.
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...
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.
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...
You assiduously pretend that this scenario isn’t possible: * The NSA reviewed the PQ submissions and realized that there’s one they already know how to break at scale: ML-KEM, because their army of math PhDs spent a couple decades understanding it better than the rest of the world * The NSA decides they want ML-KEM deployed everywhere so that the world is full of transparent-to-NOBUS cryptography * The NSA spends the entire PQ contest placing their thumbs on the scale of the process, violating their 2014 post-Snowden promises of increased transparency, to make their NOBUS dreams happen
The actions of NSA and NIST personnel make the most sense with the assumption that they desperately want to standardize ML-KEM and ML-KEM alone because _they already know how to break it_. What doesn’t make any sense is why the private sector is cheerfully going along with it —- even Charlie stopped letting Lucy hold the football at some point.
I was happy to see the lead of Europe’s PQC team also voted with the cryptographers.
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 it's use.
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 strenghtening direction...) it's possible that their influence was motivated by things like that ease of undetectable compromising specific imlementations through techniques like dopant adulteration or specialized side channel weaknesses.
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 justifies the utmost concern and caution.
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.
Address the actual claims or GTFO.
(Consider the difference between extensive peer-review and “appeal to authority”, not to mention the IETF’s dual role encouraging research along with mainstream deployments)
I do not think the response addresses the claims made, and uses logical fallacies in place of a well reasoned response.
> a team of highly-regarded European academic cryptographers
This is absolutely an appeal to authority.
This matters because academic reputation is so important in the field: none of these people can force even their own universities to adopt something and if you say they pushed something through covertly you’re making a really serious claim about a core professional trait which reflects not only on them but also many of their colleagues who reviewed and supported that proposal, and that should have evidence that this was bulled through rather than simply asserting it.
Four days ago: https://news.ycombinator.com/item?id=48760490
Because they weren't (supposedly) able to break the encryption
But w
> 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.
Maybe I said cypher for the AES+Serpent mention (and because I like cyberpunk xD)
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 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.
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?
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".
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.
«- 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_...)
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.
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"