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.
the McEliece cryptosystem goes back to the 70s, doesn't mean it's as well studied as RSA. obviously people study popular cryptographic primitives more.
having said that, I would trust McEliece more than Kyber.
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.
certainly a concern, and a good reason to use multiple cryptosystems together. unfortunately there are probably similar papers for Kyber which are NSA property and will never see the light of day. they do employ a lot of mathematicians.
for applications where key exchange need not be particularly fast or compact, I would even throw in 4096 MP-RSA in (tuned to whatever size the exchange can tolerate) as a hedge against that if a CRQC is even possible, it would be able to continue to grow in size quickly or at all.
there is no indication there are similar papers. Curiously, the best lattice cryptanalysts in the world are chinese and european (here I'm thinking of people like Ducas, Albrecht, and Ding). It's actually a weird blindspot of american cryptography (this isn't true for all cryptanalysis, but in general European cryptography is "more concrete" vs "theoretical" american cryptography).
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).
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.
Because NIST chose it, after non-public input from the NSA. But if I am honest, NIST recommending it at all is enough to suspect it of being compromised. I say that as an American, and my non-american friends equally don't trust NIST on crypto topics.
The real problem I have is best described as I haven't read a single coherent argument responding to and rejecting the real concerns raised by the individual who after nist betrayed the internet with by recommending a compromised standard at the encouragement of the NSA. Is the person who wrote the crypto library everyone uses.
DJB puts his money (time) where his mouth is. I would critique his attachment to his own ego. But I'm in the group of people who haven't contributed enough yet to foss to get to throw stones. So I'll defer to people who can match his contributions. Until that happens, DJB's reputation is cares passionately about crypto and it's community, vs an US government group with a reputation for trying to sabotage crypto systems after passing secrets with the NSA, who refuses to provide details about their most recent secret messages.
I do find some of the arguments and refutations from the mailing lists compelling. But not all the them, and nothing directly from NIST. Equally some of DJB's appear to weaken his points. But like I said, I plan to trust the reputation each party has earned.
NIST has a history of behaving inappropriately, and unethically around it's cryptography recommendations. But the people currently in charge would rather pretend they're above it and not literally directly responsible for the organization with a well earned reputation. If you're given a 2nd chance after your partner catches you cheating, it's a reasonable requirement that you account for every second of your time, until you restore the reputation you destroyed.
> But if I am honest, NIST recommending it at all is enough to suspect it of being compromised.
NIST isn't the NSA and doesn't have the NSA's goals in mind. They are briefed by NSA on some matters, sure, but they're not the same organization.
NSA has a dual mission: Both SIGINT and COMINT. While the SIGINT folks might rub their hands and laugh evilly at the prospect of backdooring the PQ KEM that the Internet wants to move towards, this plot makes no sense at several levels.
The NSA has, through CNSA 2.0, committed to moving the entire federal government onto ML-KEM for top secret communications. The COMINT guys would shit themselves in rage if it turned out to be backdoored, even if there was enough hubris that the backdoor was NOBUS.
If you can't trust the people, you should always seek to understand their incentives if you want to predict their behavior.
My interpretation of the CNSA 2.0 move was that the NSA believes 1) that ML-KEM is actually the good stuff, and 2) the Suite B transition failed so spectacularly that they want to signal confidence in ML-KEM by recommending it without hybridization. Since pretty much everything they do is top secret, they probably can't comment further.
You're argument is that I shouldn't think of NIST as a patsy for the NSA, is because the NSA can't possibly be recommending a compromised cipher, because if they were, that would mean this US government org is horribly defective and dysfunctional, where one side didn't know what the other was doing?
Incentives are basically all I consider when trying to establish true motive. But you're not required to consider motive when there's a history or pattern. Even if "It's the way we've always done it", wasn't a much, much stronger motive than thought/reason is for any human. It's both logical and desired to treat something as the most dangerous until proven otherwise.
I used to be a nurse. I remember when working in the ED, I was taught that every single woman on childbearing age who comes into the ED with abdominal pain is an extopic pregnancy until proven otherwise. If you ask a woman if it's possible she could be pregnant, regardless of the truth, many will claim it's impossible. If you blindly trust them, and delay treatment, you could needlessly kill your patient, or leave them infertile. Why would someone lie and risk that? Or how dare your medical team make assumptions like that? Well the alternative is worse, the reality should be easy to prove.
NIST has a history of recommending broken ciphers. That's not a mistake a professional would ever make. So thinking about incentives, I'm going to treat it like it was intentional. Here the group with a history for fucking up, isn't being transparent. I would love it if NIST would say enough to make DJB happy or at least stop pretending like they deserve any trust anymore.
Until then, I don't find "they're probably behaving like rational actors" compelling enough to trust them with keeping secrets from somebody who I actually do trust.
In the past NSA has weakened encryption standards, for example NSA madified DES standard. The NSA pushed backdoored design of Dual_EC_DRBG was standardized in NIST SP 800-90A.
"Weaknesses in the cryptographic security of the algorithm were known and publicly criticised well before the algorithm became part of a formal standard endorsed by the ANSI, ISO, and formerly by the National Institute of Standards and Technology (NIST). One of the weaknesses publicly identified was the potential of the algorithm to harbour a cryptographic backdoor advantageous to those who know about it—the United States government's National Security Agency (NSA)—and no one else. In 2013, The New York Times reported that documents in their possession but never released to the public "appear to confirm" that the backdoor was real, and had been deliberately inserted by the NSA as part of its Bullrun decryption program."
"NSA worked closely with IBM to strengthen the algorithm against all except brute-force attacks and to strengthen substitution tables, called S-boxes. Conversely, NSA tried to convince IBM to reduce the length of the key from 64 to 48 bits. Ultimately they compromised on a 56-bit key"
NSA Suite A was probably used for Space Shuttle comunication. NASA scrambled to recover classified communications gear after the Challenger shuttle disaster in 1986.
This argument is entirely non-falsifiable. You could use the same logic no matter what algorithm won the PQC competition. You can even use Vizzini logic to argue against against algorithms the NIST competition didn't pick.
I'm not making a falsifiable argument. I'm stating that given their history, and current behavior I don't trust NIST and I don't think anyone else should either. They are keeping secrets around a new crypto system, the last time they did that it was to hide a known-broken crypto system.
The controversy over the PQC is the topic at hand. If they'd selected a cipher that didn't carry the objections of someone who's reputation I trust more than NIST. Then I'd trust NIST's decision, by proxy.
if you blindly distrust the NSA, you should stop using x25519 immediately. It uses SHA2, which was solely developed by the NSA.
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?
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 do think it's fair to make an argument that DJB's expertise in practical cryptography (both in e.g. engineering against side channel attacks as well as in publishing his own libraries) gives him a reality-minded perspective/attitude.
That said, personally speaking, his behavior as a software publisher (packaging & whatnot) is something I'd call… let's go with "subpar" and leave it at that. So while I do believe it's a fair argument, I'm not accepting it, because from my perspective he isn't putting in the necessary work to really understand software publishing.
Bernstein as a "software publisher" cannot really be compared with anyone else, because what can be considered as great flaws in comparison with others are compensated by equally great advantages.
He has published a very large quantity of open-source software, but after publication he never bothered with any kind of maintenance, which is understandable, because he went on doing other work.
On the other hand, unlike almost any other software packages, those published by him almost did not need any maintenance. The only required changes, after decades since they were written, have been caused by external changes, e.g. the continuous evolution and instability of the Linux APIs and the replacement of various IETF RFCs.
I am still using several software packages written by DJB, which have been run continuously 24/7 for more than a quarter of century, on many servers, without ever causing any kind of problems or incidents, unlike a lot of much more notorious software packages, which had various bugs despite permanent maintenance.
Ah I see what you were trying to say. It read to me (with "He's a cryptographer. You're describing cryptographers.") like you were dismissing that knowledge about implementing and shipping cryptographic libraries is a relevant expertise (or that every cryptographer would have that, which they absolutely don't.) But, yeah, he's one among a whole bunch of experts in some of these fields and certainly shouldn't be given special weight just due to his name recognition.
Even the side channel stuff in particular --- Bernstein was certainly a popularizer of it, but that's been mainstream in cryptography research since the mid-2000s (and, obviously, it's Paul Kocher's claim to immortality).
One very big problem I have with Bernstein's recent activism is the way he writes to an audience you can just very clearly tell he thinks little of. He's assuming everybody who pays attention to this stuff has paid basically no attention at all to any cryptography he himself didn't write about. It's a bad argument, but that's not my big issue; my big issue is that he's making fools of his supporters. Not OK.
Huh, seen through that light, it's much clearer why we should all have ECC in our cryptosystems, because nothing has ever gone wrong with an ECC implementation.
This reads to me as an argument of "If you thought ECDSA was bad, wait until you see MLKEM?"
ECDSA history is repeating itself again when you consider how poorly the proposed MLKEM RFC deals with side channel resistance:
From draft-ietf-tls-mlkem-8:[1]
"Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."
From NIST SP 800-227:[2]
"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."
MLKEM is more complex and has more chances of stuff-ups in implementation than ECDSA did. A single sentence of encouragement is all that is on offer from this MLKEM RFC. It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]
As a point of reference for how hard it is to implement side channel resistant MLKEM see [4] (formal verification) and [5] (errors in formal verification). The MLKEM RFC doesn't offer a "Security Considerations" section to explain how difficult it is to implement side channel resistant MLKEM (perhaps it's easy :S), and if it were hard to implement, to recommend use of EdDSA+MLKEM for cryptography implemented on devices an attacker may be able to physically access, or when used on public networks as a workaround given that side channel resistant EdDSA would be easier to implement.
> A single sentence of encouragement is all that is on offer from this MLKEM RFC.
The draft only specifies the MLKEM binding into TLS; it'd be out of scope for it to go into detail on implementation considerations for MLKEM. Those would belong in or adjacent to FIPS 203 (the actual MLKEM specification).
> It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]
It's actually RFC8032 that this criticism would apply to, since it is actually specifying EdDSA, not just referencing it externally.
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. 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.
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.