verification also requires computing the jacobian. an undergraduate-level exercise, but harder than verifying p(pt1) == p(pt2).
405 karma · joined April 7, 2026
E.g x: ZmodN == y: ZmodN is a different operation than x: Z == y: Z, but they're both the equality operation. We wouldn't makeup a new name for addition in this context.
It's also worth mentioning we can use the equality function (==): Z x Z -> bool to define the (==_N): ZmodN x ZmodN -> bool function in a semi-generic way. To do so, we "just" need a way to assign a unique representative (in Z) to any x: ZmodN. In other words, this is choosing a partial inverse to the reduction function modN: Z -> ZmodN. I think the partial inverse is a right inverse? so a function g : ZmodN -> Z such that (modN) o g x == x for all x in ZmodN. Anyway, given such a right inverse g, you can define (==_N): ZmodN x ZmodN -> bool via
(==_N) x y := (==) (g x) (g y)
This has the benefit that it doesn't treat ZmodN as special in any way. You can apply the same song and dance for more general quotient structures. This can be useful when doing e.g. matrix arithmetic, where you might want equivalence up to the choice of some rotation or something.
https://github.com/llvm/llvm-project/pull/166702
note that this isn't the only "trick" needed for constant-time programming though. Indexing an array with a secret index needs its own trick, for example.
I agree that trying to trick the compiler is very ugly. A well-known applied cryptographer has a paper from last year saying that not only is it ugly, but it doesn't work particularly well, and if anything the trendline of the various "tricks" is that they get less effective over time.
applied to the step function, you would get a smooth cutoff function
https://en.wikipedia.org/wiki/Mollifier#Smooth_cutoff_functi...
this is also related somewhat to the notion of differentiable programming. RELU is (roughly) the same as x * step(x). In differentiable programming one can replace it with smooth approximations, cf "softplus"
https://arxiv.org/pdf/2403.14606
That book also has a chapter on control flow, which is very similar to what you're talking about.
Unrolling an if statement into x = b (result of one branch) + (1-b) (result of the other branch) is also incredibly common in cryptography. If `b` is a "secret" variable, an if statement may leak the value of it via the branch predictor/speculative execution. The way around this is to compute both branches, and then select them with the above arithmetic expression. This mostly works, though compilers are tediously smart, and so one often has to be careful how with how you precisely do it.
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.
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.
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
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://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).
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.
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).
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?
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.
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.
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.
This was still a very bad policy, but private americans were allowed to have strong cryptography.
1. the payment to RSA (in 2004) was secret. So it could not have been a public indication of a problem, as it was not discovered until nearly a decade after it happened (in 2013, when it became public)
2. the problematic part of DUAL_EC_DRBG (the "hint of a backdoor") I was mentioning was known pre-2004.
blind paranoia is not a rational approach to cryptography. I say this as someone who prefers hybrid schemes! I just don't think it is sensible to attempt to "ban" the usage of pure ML-KEM by not standardizing it. It won't work! It'll just increase the risk of non-interoperable implementations.
For DUAL_EC_DRBG, the mechanism that could yield a backdoor was known pre-standardization. To get the backdoor RSA had to specifically use government chosen parameters.
These are not new concerns. If even a candidate backdoor had appeared in ML-KEM (similarly to how DUAL_EC_DRBG was), it would be a very different story. But nobody has ever even suggested something might be off!
So no, it's not exactly the same as DUAL_EC_DRBG. Different things are in fact different. Note that there are similarities to DUAL_EC_DRBG in contemporary cryptography. Russia has a block cipher Kuznyechik that has some very fishy structure in its S-box. We don't know how such structure is exploitable, but I would bet money that it is. Despite not being able to see an attack, we can see that things seem off in a concrete way. Nobody has *ever* suggested that for ML-KEM.
Again explicitly, this is not the main RFC for PQ TLS, which details a hybrid construction. This is an RFC with "recommended to implement = N" marked about how to do PQ TLS 1.3 in environemnts where hybrids are too expensive, for example hardware where it necessitates both a SHA2 and SHA3 impl.
That blog post is written in a way that implies otherwise, namely that pure ML-KEM is being favored over hybrids for TLS 1.3. This is explicitly false.
Moreover many parts are technically false. In particular, the claim that hybrids are negligible cost in all circumstances is false in low-spec hardware, as it necessitates both a SHA2 and SHA3 implementation.
https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9...
The variant DJB suggests there are explicit risks. For example
1. both ECC and ML-KEM can be broken (obviously)
2. additional code complexity could increase the LoC of teh crypto implementation, making it more plausible there are implementation bugs
regardless, this is a red herring. Nearly all cryptographers still support hybrids!!! The current RFC is *not* about "use pure ML-KEM". It is instead about "if you're going to use pure ML-kem (and we explicitly recommend not doing so), here is how to do it in a standardized way".
The people arguing about this decision don't even know what the decision being made is in the first place.