He didn't publicly call me an NSA shill, so I got off pretty easy. Obviously, I stand by what I said. I think it would be an understatement to suggest support for what Bernstein is arguing is a minority cause among cryptographers.
The argument from Roberto Avanzi is reasonable: "as a codesigner of ML-KEM myself I would not trust using it exclusively: what if it gets broken mathematically and in the classical computational model (I.e. non-quantum)? Hybrid is better, and the additional time used by ECC is not significant."
A majority (but not a large majority) of cryptography engineers would use hybrids at this point, and hybrids are largely the default design for any mainstream deployment. Bernstein argument isn't "use hybrids, not pure MLKEM"; it's "MLKEM is so dangerous there shouldn't even be an informational standard saying how to use it". That's a problem, because there are non-mainstream deployment environments where you can't use hybrids.
Obviously, Bernstein is counting on you not following that level of nuance; he'd much rather you believe he's arguing for hybrids against people who are trying to exterminate hybrids.
For clarity: I am not a cryptographer; I'm a vulnerability researcher who does some cryptography work and for several reasons I talk to a lot of academic cryptographers and cryptography engineers. You could not pay me to design a PQC transport protocol for you.
I haven’t read much of the for or against, so it’s certainly possible there’s a whole hidden web of ulterior motives at play here that I’m unaware of (rather than just “there’s a lot of pre-existing bad blood I’m unaware of, which is why both sides are snippy and pedantic”), but I feel compelled to object to this “nuance” point you make. The argument I see being made is “there is NSA pressure to document standalone MLKEM, so that there can be NSA pressure to adopt standalone MLKEM”, which seems fairly straightforward and without nuance to me.
Just so we're clear, you're acknowledging that this argument hinges on the idea that documenting pure MLKEM is dangerous because, once it's documented in an (informational, optional) RFC, but only if it's documented in an RFC, NSA will pressure people to adopt it.
You're working real hard here to misunderstand his point and ignore historically relevant actions by NSA which have weakened and introduced attack vectors into previous standards, facilitating their adoption by orgs worldwide.
Yes, the argument is MLKEM is so dangerous that it shouldn't be used alone. Even its codesigner says so. Why is it so hard to accept?
Take a look at the crypto from the 80's and 90's. They are considered bad jokes nowadays, badly designed and easily breakable. Why would the first-generation PQC algorithms be any different? Of course they're going to be broken and ridiculed in 20 years, in ways you cannot comprehend yet
I feel like what's most likely happening here, given your initial argument, is that you just learned that this is a debate about whether it should be forbidden to even document a particular MLKEM configuration, and you're now working backwards to the proposition that Bernstein is right.
To that I will only add that lattice cryptography is of approximately the same vintage as elliptic curve (both started in the late 1990s) and MLKEM is past the level of maturity relative to lattices that 25519 was relative to the original P-curves. (Correct me where I'm wrong here --- this is off the top of my head). This isn't "the first generation" of anything.
Just another nuance I think Bernstein is counting on you, the real audience for these posts, not having any intuition for.
In addition to noticing that your argument had moved goalposts (the part you claim is an ad hominem, but is not) I also responded substantively to a factual claim you made, and you're pretending otherwise.
> A majority (but not a large majority) of cryptography engineers would use hybrids at this point
Actually, based on the WGLC, or the three of them rather, it's pretty clear that Ph.D cryptographers significantly prefer hybrid over pure ML-KEM.
> he'd much rather you believe he's arguing for hybrids against people who are trying to exterminate hybrids.
The brigade by the NSA (6+ votes or more if you include NSA contractors), the AD being former NSA and the moderation of Dr. Bernstein for a footnote seems pretty fair and balanced </sic>.
Meanwhile, the lead of the EU PQC program, professors from several universities, Ph.Ds and, additionally, legendary cryptographers all expressed significant concern and even stronger opposition to the publishing of the draft.
Finally, the chairs refused to share their methodology in determining consensus when asked by several Professors and Ph.Ds.
I'm confused by your messages linked by DJB. You say that better cryptographers would not choose hybrids, which seems to say that you should indeed think that hybrids are not a good choice. Then you say you are not such a good cryptographer and would choose a hybrid. But if you know that more senior cryptographers think they are not the right choice then why choose them anyways? Or am I misreading "cryptography-literate" here?
Can you explain a bit more regarding your statement that DJB's POV on the matter has no broad support amongst his peers? I'm not in the field but Bernstein seemed like a highly respected member with a long track record in the crypto community, at least from the outside. Do you think the community is wrong or is it DJB who's wrong and why? There's also a good chance that I totally missed the argument being made.
I can think of several academic cryptographers (or rather, practitioners with doctorates) who think the hybrid/pure thing is silly. I didn't claim that a majority oppose hybrids. The point of the message he snipped from the HN thread is that pure MLKEM is not considered an unserious design by actual cryptographers (people on the HN thread --- generally not cryptographers, like me --- think it is). Cryptography engineers tend to default to hybrids.
Downthread we develop more clarity about what it is Bernstein is actually in an argument about. It isn't hybrids vs. pure!
I can think of academic practitioners with doctorates who had wildly disastrous opinions about their field of expertise too:
Peter Duesberg, a Ph.D. in molecular biology / retrovirology who taught at Berkley and was a member of the National Academy, who maintained that HIV does not cause AIDS and that antiretroviral drugs do more harm than good.
Walter Freeman, M.D. academic neurologist and first chair of neurology at George Washington University who believed that severing frontal-lobe connections could stabilize personality and stop pathological cycles of thought.
Charles B. Davenport, Ph.D. in biology, geneticist and founder of the Eugenics Record Office.
Henry H. Goddard, Ph.D. in psychology, intelligence-testing researcher and later professor of abnormal psychology who believed intellectual disability, poverty, prostitution, and criminality constituted a hereditary family type.
Clarence Cook Little, Harvard Ph.D., mammalian geneticist and prominent cancer researcher who insisted for years that the evidence did not establish a causal relationship between smoking and lung cancer.
Fun game. We could laugh at all of them, and your examples too, if not for the damage they caused.
“Als Appelbaum im September 2015 an der Technischen Universität Eindhoven ein Doktorandenprogramm beginnt, ist auch sie interessiert. Für Appelbaum ist die Universitätsstelle in Eindhoven auch eine existentielle Stütze, falls er, nach den Vorwürfen im März in Valencia, seine Arbeit beim Tor-Projekt nicht fortsetzen kann. Lovecruft versucht schließlich, bei den selben Professoren wie Appelbaum angenommen zu werden. Am Ende wird ihr das nicht gelingen. Ein anderer Mensch wird jedoch das Büro beziehen, das direkt neben Appelbaums liegt. Es ist der Lebenspartner von Isis Agora Lovecruft oder einer ihrer Lebenspartner, das ist nicht klar. Dieser Mann wird später Arbeiten von Appelbaum bewerten, deren Ergebnisse für dessen Vorankommen in der Universität wichtig sind.
Im Januar 2016, kurz nachdem sie an der Universität in Eindhoven abgelehnt wird, beteiligt sich Isis Agora Lovecruft daran, Geschichten zu sammeln über Jacob Appelbaum.”
The person this is about is not an acquaintance of mine. I have no idea if they applied or didn't apply. The person I've spoken to --- am acquainted with (though not personal friends with) is Henry de Valence, who obviously did not lose a spot in Bernstein's lab to Appelbaum.
These are all incredibly creepy and inappropriate accusations for you to be making. They're also wildly against the site guidelines.
No creepier than the way you're in every one of these threads argument-botting djb. The co-designer of ML-KEM can steelman DJB's point, despite his very personal involvement. Which causes folks to question why your reactions would be so much stronger than those of the directly involved. You blame folks for looking for reasons?
If you don't want people to question your motivations, don't behave like someone with questionable motivation. Seems simple.
Bernstein is a co-author on NIST PQC competition submissions that didn't win (Classic McEliece, which just had a huge new research result, and Streamlined NTRU Prime, a lattice cousin to MLKEM).
When CRYSTALS/Kyber was selected in the NIST competition instead of SNTRUP, Bernstein didn't take it well. He claimed malfeasance by NIST and sued them for allegedly hiding documents.
Meanwhile, over the subsequent years, the world has continued turning on its axes. CRYSTALS/Kyber is now ML-KEM. Because many cryptography engineers and other security people think there's a lot of urgency to getting PQC deployed (because of harvest-now decrypt-later [HNDL] attacks), the IETF got a move on standardizing hybrid ECDH/MLKEM TLS 1.3, which is what everyone uses.
Nobody at IETF has ever to my knowledge even hinted that anyone should avoid hybrids. There is a standards-track RFC defining ECDH/ML-KEM hybrids.
There are environments where hybrids are problematic. You won't likely use any of them ever. Some of them occur within the US Government, and some of them are on highly constrained platforms (people seem to disbelieve this is ever really a thing but I once gameovered a smart meter because its RF protocol only had like 16 bits of counter space for CTR).
Because of this, there is also a proposed informational RFC --- not a standards track document --- that documents what pure MLKEM looks like in a TLS 1.3 setting. Bernstein's entire argument is that this is an NSA plot.
> Because of this, there is also a proposed informational RFC --- not a standards track document --- that documents what pure MLKEM looks like in a TLS 1.3 setting.
For discussion on Bernstein's objection to that IETF draft see article from ~month ago, "NSA and IETF: Fairness":
RFCs are used by developers as strict guidelines for implementation.
The mere publishing of an RFC has customarily been treated by developers as a stamp of approval from the IETF.
The NSA, contractors and their fans argue that simply adding a "RECOMMENDED=N" in an obscure section of this draft will somehow prevent said implementations in deployments.
However, as an example, Canada's NSA equivalent specifically requested the draft to be published so that they can use it to support their poor choice in deployment of solo ML-KEM nation-wide.
While ML-KEM may be sound, significant bugs in implementations in the wild continue to be published.
To be clear, CRQCs do not exist today.
ECC is battle tested, proven, and is used today.
It makes no sense to delete working cryptography and replace it with potentially buggy, non-battle tested implementations of new cryptography for a threat that does not yet exist today.
Instead, you fight HNDL [1] with hybrid which preserves the safety of today, and hopefully also, tomorrow.
No serious security person should be recommending otherwise which is, perhaps, why some may question the motives of those that are pushing for solo ML-KEM.
It's never been clear to me why NSA's "blue team" directorates haven't been spun off into a separate agency. Sure, NSA strengthened the S-boxes in DES and SHA-1 but from the outside there's no way to know whether they're making DES stronger against differential cryptanalysis or whether they're introducing a DUAL_EC-style vulnerability.
I'm sure there's a game-theoretic optimum choice when it comes to accepting proposals from the NSA vs rejecting them out of hand, but I'm not sure what that optimal choice is.
Imo "the optimal choice" is to be extremely skeptical to what comes to NSA proposing anything related to encryption/cryptography. From the first part of this blog series by DJB[1]:
> Try to put yourself in the mindset of NSA as an attacker. You have a massive budget to "covertly influence and/or overtly leverage" systems to "make the systems in question exploitable"; "to the consumer and other adversaries, however, the systems' security remains intact". One of your action items is to "influence policies, standards and specification for commercial public key technologies". Another is to "shape the worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS".
And when you read the Snowden docs and you come across to things like this 2010 GCHQ presentation[2], stating "for the past decade, NSA has lead an aggressive, multipronged effort to break widely used Internet encryption technologies" such as "SSL" and "SSH" and "VPNs"; that "cryptanalytic capabilities are now coming on line"; and that "vast amounts of encrypted Internet data which have up till now been discarded are now exploitable."
So we have these agencies like NSA and GCHQ, with stated, funded programs to make deployed cryptography exploitable (and historical evidence of them successfully doing just that)... It's an unbelievable conflict of interest for them to hold any role where they can shape what gets deployed. Absolutely bonkers.
And on DES specifically, it was both at once, not a binary. NSA in secret pushed IBM to cut the key size, while strengthening the algo against every attack except brute force. The design criteria were classified and IBM's own research docs were literally locked up under gov classification at NSA's request meanwhile when IBM personnel publicly denied any NSA involvement (and the NSA director publicly denied any algo weakening, again, a lie). So DES came out genuinely hardened against differential cryptanalysis but at the same time breakable by brute force by organizations with budgets like NSA's, by NSA's request/order.
For the "blue team" thing.. I guess it's actually better for them tactically to not spin off, because being NSA gives you authority in those circles. Standards bodies don't seem to treat the conflict of interest as a problem (as we can see), but rather as a qualification ("people who know cryptography best").
I thought this was going to be rehashing of the old NULL-cypher IPsec thread, but it’s a different thing.
Maybe we should treat standards like we do a free market - let anyone implement what they choose then let people chose which to adopt, but the main thing is get government out of the entire process.
If the government wants to standardise, that’s fine… just don’t make it an industry standard adopted by civilians. Let them have their weakened protocols will the market moves on
> I'm happy to report that 82 people spoke up on the TLS mailing list in unambiguous opposition to this spec during the voting period
How many of them spoke before on this mailing list, in any capacity what so ever? I suspect this is 99% people who showed up because you organized a brigadging, because you incited people and told them to show up and be completely outraged.
There's a >0% chance that DJB could be correct that there is some risk to this spec (which notably is not seeking recommendation status! So WTF?) The people approving and wanting this aren't fools, aren't lackies, aren't some great foe. There's little real opposition? Making up ghosts and enemies lurking in every corner, brigading people to show up in IETF meetings, who have never participated before, just to spread heat and anger you've programmed them for, is ignoble & indecent.
> which notably is not seeking recommendation status!
I don’t have a dog in this fight, but some extremely important RFCs are only on the “informational” track. RFCs 1945 (HTTP 1.0), 4627 (JSON), 2818 (HTTPS), etc.
As far as I know HTTP 1.0 doesn't have a standards-track RFC (HTTP 1.1 and later do). JSON and HTTPS do indeed have standards-track RFCs, but I stand by my original wording that their first informational RFCs were "extremely important."
That’s a very unfair position to take when dealing with secret agencies who try very hard to obfuscate this stuff - it is hard to provide evidence for in the moment.
The government has intentionally acted to weaken DES, standardized Dual_EC_DRBG, performed subtle subterfuge through interfering how NIST operates to inject weaknesses and vulnerabilities, trying to weaken SSL and IPSec, 4G smartphone encryption.
These are all documented examples of the NSA engaging in bad faith. So whether or not it is happening in this particular case, there’s now just zero trust in the institutions acting in good faith. And given it took decades for the actions to come out after they were taken, how do you expect someone to answer your request to present evidence there’s anything nefarious happening now?
Anyway, that’s what I think a fleshed out argument would look like
It's a simple question. I'm not asking anybody to prove anything. I'm literally asking: propose the PQC standard IETF could have subverted, and give a sketch of how they could have done it. The bar is merely "plausibility". I'm not asking whether NSA has subverted standards before; obviously they have.
NSA, by the way, rescued DES from differential cryptography, the core mechanism by which block ciphers and hash functions have been attacked ever since.
They did both - they strengthened it from differential integrity but weakened it by picking a known-to-be-too-short key length. Meaning they had the compute power to crack it but others couldn’t do the same through pure algorithmic means.
As for your post below
> it can't be that NSA simply knows a vulnerability that impacts one very specific lattice scheme and not the others
Ok. My argument is they know all lattice schemes are weak and the push to use a lattice-only scheme is precisely to have a cryptographic mechanism they can easily bypass without a classical known-secure backstop.
See, here's another argument that doesn't work here, because Bernstein very publicly backs a different lattice cryptography scheme.
In addition to the previously-stated reason why that argument is inoperative (besides being unfalsifiable, it admits a strategy where NSA "poisons the well" to get people to avoid a particular construction or family of algorithms, so that we all move to weaker ones --- a counterfactual that should be much more vivid after what was released this week!)
> NSA, by the way, rescued DES from differential cryptography, the core mechanism by which block ciphers and hash functions have been attacked ever since
That's why you use ML-KEM 1024 at all... As part of a hybrid.
There is no public reason to think that 1024 is better than 768, or DJB's S-NTRU-P 761. The NSA might know something, but we can't trust them. So, use a hybrid, in case they are really just trying to protect us.
That can't be the argument --- it can't be that NSA simply knows a vulnerability that impacts one very specific lattice scheme and not the others. The reason for that is a cryptographic concept known as the Vizzini Conjecture: the argument you just put forward can be applied to literally any cryptographic standard NIST authors. Since NSA knows that, and knows you know it, you can clearly not choose the wine in front of you. It must be that the standard NIST picks is the only secure one, so that NSA can see it tainted by NIST association.
But yes, this is the useful conversation to have. There are other scenarios! You can get into more detail on where MLKEM came from, for instance.
Yes, they trick me and I pick the poisoned wine... But wait, no, I used a hybrid. Imagine the code can't be backdoored (it's proven not to crash/be slow/be exploitable) so at worst it can make the security no better. At best, the NSA knows a whole new subfield of cryptography (from history: differential cryptanalysis) and it really is more secure.
They laugh at us while we try to think of how 1024 is better than 768: "bigger is better, right?" "does 1024 refer to the number of years it takes Nightmare Moon to break the code?"
There is nobody at IETF saying you shouldn't use a hybrid! In fact, it's the exact opposite: hybrid ECDH/MLKEM is a standards-track RFC, and the proposed pure-MLKEM RFC is not, nor is it "Recommended" (in IETF parlance).
Let's keep the thread coherent: the original claim, by cryptographer 'cassonmars, is that the issue here is NSA pushing bad standards. It's not "hybrid vs. pure", which is a non-issue. All I asked for was a plausible story about how NSA might have pushed a bad PQC standard.
> Let's keep the thread coherent: the original claim
How do you save your poisoned wine? A hybrid with 1024 is made less trustworthy if the NSA pushes 1024 alone, since then we know that they want customers to use 1024 alone, which is what they would want if it was weak. But they know that we would know that, so if they really want to help us they should withdraw the draft. If it was strong but we know why, they shouldn't want to make us doubt ourselves. If it is strong (and 512 and 768 are not) they can't tell us, and can only subtly point to their own double encryption and security level documents. The only move that can cover all the cases is a hybrid with 1024, so this draft is a bad standard.
Re "NSA rescued DES from differential cryptography":
I coined the name Deep Crack for the EFF machine that brute-forced DES in 56 hours on a $250K budget. Ostensibly a play on Deep Blue and Deep Thought. The official hidden message, per my email in 1998: there's a Deep Crack in the government's export control policies. Unofficial hidden message: they strengthened DES against every attack except the one their budget could afford.
Not responsible for allusions to the Liberty Bell, Marion Barry's favorite nose candy, Mark Felt's alias, Linda Lovelace's famous movie, or Douglas Adams's computer that answered forty-two. Responsible for the observation that when someone says NSA "rescued" a standard, it's worth asking what crack they left in it for themselves.
The first key's free!
Deep Crack origin story (Denise Caruso + Gilmore + Hopkins, 1998):
Brings to mind this lovely quote from the Snowden documents:
“The road to developing this standard was smooth once the journey began... However, beginning the journey was a challenge in finesse ... After some behind-the-scenes finessing with the head of the Canadian national delegation and with C.S.E., the stage was set for N.S.A. to submit a rewrite of the draft ... Eventually, N.S.A. became the sole editor.”
I enjoyed the @tptacek cameo. I suspect tptacek didn’t.
He didn't publicly call me an NSA shill, so I got off pretty easy. Obviously, I stand by what I said. I think it would be an understatement to suggest support for what Bernstein is arguing is a minority cause among cryptographers.
The argument from Roberto Avanzi is reasonable: "as a codesigner of ML-KEM myself I would not trust using it exclusively: what if it gets broken mathematically and in the classical computational model (I.e. non-quantum)? Hybrid is better, and the additional time used by ECC is not significant."
A majority (but not a large majority) of cryptography engineers would use hybrids at this point, and hybrids are largely the default design for any mainstream deployment. Bernstein argument isn't "use hybrids, not pure MLKEM"; it's "MLKEM is so dangerous there shouldn't even be an informational standard saying how to use it". That's a problem, because there are non-mainstream deployment environments where you can't use hybrids.
Obviously, Bernstein is counting on you not following that level of nuance; he'd much rather you believe he's arguing for hybrids against people who are trying to exterminate hybrids.
For clarity: I am not a cryptographer; I'm a vulnerability researcher who does some cryptography work and for several reasons I talk to a lot of academic cryptographers and cryptography engineers. You could not pay me to design a PQC transport protocol for you.
I haven’t read much of the for or against, so it’s certainly possible there’s a whole hidden web of ulterior motives at play here that I’m unaware of (rather than just “there’s a lot of pre-existing bad blood I’m unaware of, which is why both sides are snippy and pedantic”), but I feel compelled to object to this “nuance” point you make. The argument I see being made is “there is NSA pressure to document standalone MLKEM, so that there can be NSA pressure to adopt standalone MLKEM”, which seems fairly straightforward and without nuance to me.
Just so we're clear, you're acknowledging that this argument hinges on the idea that documenting pure MLKEM is dangerous because, once it's documented in an (informational, optional) RFC, but only if it's documented in an RFC, NSA will pressure people to adopt it.
You're working real hard here to misunderstand his point and ignore historically relevant actions by NSA which have weakened and introduced attack vectors into previous standards, facilitating their adoption by orgs worldwide.
Absolutely, that’s more or less exactly what I took away from it.
Yes, the argument is MLKEM is so dangerous that it shouldn't be used alone. Even its codesigner says so. Why is it so hard to accept?
Take a look at the crypto from the 80's and 90's. They are considered bad jokes nowadays, badly designed and easily breakable. Why would the first-generation PQC algorithms be any different? Of course they're going to be broken and ridiculed in 20 years, in ways you cannot comprehend yet
I feel like what's most likely happening here, given your initial argument, is that you just learned that this is a debate about whether it should be forbidden to even document a particular MLKEM configuration, and you're now working backwards to the proposition that Bernstein is right.
To that I will only add that lattice cryptography is of approximately the same vintage as elliptic curve (both started in the late 1990s) and MLKEM is past the level of maturity relative to lattices that 25519 was relative to the original P-curves. (Correct me where I'm wrong here --- this is off the top of my head). This isn't "the first generation" of anything.
Just another nuance I think Bernstein is counting on you, the real audience for these posts, not having any intuition for.
That's a weak ad hominem deflection. Readers be the judge.
In addition to noticing that your argument had moved goalposts (the part you claim is an ad hominem, but is not) I also responded substantively to a factual claim you made, and you're pretending otherwise.
> A majority (but not a large majority) of cryptography engineers would use hybrids at this point
Actually, based on the WGLC, or the three of them rather, it's pretty clear that Ph.D cryptographers significantly prefer hybrid over pure ML-KEM.
> he'd much rather you believe he's arguing for hybrids against people who are trying to exterminate hybrids.
The brigade by the NSA (6+ votes or more if you include NSA contractors), the AD being former NSA and the moderation of Dr. Bernstein for a footnote seems pretty fair and balanced </sic>.
Meanwhile, the lead of the EU PQC program, professors from several universities, Ph.Ds and, additionally, legendary cryptographers all expressed significant concern and even stronger opposition to the publishing of the draft.
Finally, the chairs refused to share their methodology in determining consensus when asked by several Professors and Ph.Ds.
The legendary cryptographer that isn't Orr Dunkelman that you're referring to would be...?
What's noteworthy about the last list of sponsors of his position that Dan Bernstein posted was how few of them were cryptographers.
> Orr Dunkelman
The great Dr. Orr Dunkelman was admirably vocal in his opposition to the publishing of this draft.
Are you a cryptographer?
I am. I literally hold six patents around secure key generation and management. I stand by DJB's points.
Amazing. Six patents! I sign literally everything I write here with my own name, so it's pretty easy to find out my background.
[dead]
I'm confused by your messages linked by DJB. You say that better cryptographers would not choose hybrids, which seems to say that you should indeed think that hybrids are not a good choice. Then you say you are not such a good cryptographer and would choose a hybrid. But if you know that more senior cryptographers think they are not the right choice then why choose them anyways? Or am I misreading "cryptography-literate" here?
Can you explain a bit more regarding your statement that DJB's POV on the matter has no broad support amongst his peers? I'm not in the field but Bernstein seemed like a highly respected member with a long track record in the crypto community, at least from the outside. Do you think the community is wrong or is it DJB who's wrong and why? There's also a good chance that I totally missed the argument being made.
I can think of several academic cryptographers (or rather, practitioners with doctorates) who think the hybrid/pure thing is silly. I didn't claim that a majority oppose hybrids. The point of the message he snipped from the HN thread is that pure MLKEM is not considered an unserious design by actual cryptographers (people on the HN thread --- generally not cryptographers, like me --- think it is). Cryptography engineers tend to default to hybrids.
Downthread we develop more clarity about what it is Bernstein is actually in an argument about. It isn't hybrids vs. pure!
I can think of academic practitioners with doctorates who had wildly disastrous opinions about their field of expertise too:
Peter Duesberg, a Ph.D. in molecular biology / retrovirology who taught at Berkley and was a member of the National Academy, who maintained that HIV does not cause AIDS and that antiretroviral drugs do more harm than good.
Walter Freeman, M.D. academic neurologist and first chair of neurology at George Washington University who believed that severing frontal-lobe connections could stabilize personality and stop pathological cycles of thought.
Charles B. Davenport, Ph.D. in biology, geneticist and founder of the Eugenics Record Office.
Henry H. Goddard, Ph.D. in psychology, intelligence-testing researcher and later professor of abnormal psychology who believed intellectual disability, poverty, prostitution, and criminality constituted a hereditary family type.
Clarence Cook Little, Harvard Ph.D., mammalian geneticist and prominent cancer researcher who insisted for years that the evidence did not establish a causal relationship between smoking and lung cancer.
Fun game. We could laugh at all of them, and your examples too, if not for the damage they caused.
frankly every time this topic comes up he's quick to try to spread disinformation on djb's posts, so it's about time he got mentioned
Every. Single. Time. And vehemently. Like clockwork, or a job.
[flagged]
I have no idea what the fuck you're talking about here but nobody "lost a grad school spot" to Jacob Appelbaum.
It is true that I was once a Bernstein stan. He's generally been nothing but nice to me. But then I met other cryptographers.
Quoting https://archive.fo/3QWJF#selection-801.0-805.168
“Als Appelbaum im September 2015 an der Technischen Universität Eindhoven ein Doktorandenprogramm beginnt, ist auch sie interessiert. Für Appelbaum ist die Universitätsstelle in Eindhoven auch eine existentielle Stütze, falls er, nach den Vorwürfen im März in Valencia, seine Arbeit beim Tor-Projekt nicht fortsetzen kann. Lovecruft versucht schließlich, bei den selben Professoren wie Appelbaum angenommen zu werden. Am Ende wird ihr das nicht gelingen. Ein anderer Mensch wird jedoch das Büro beziehen, das direkt neben Appelbaums liegt. Es ist der Lebenspartner von Isis Agora Lovecruft oder einer ihrer Lebenspartner, das ist nicht klar. Dieser Mann wird später Arbeiten von Appelbaum bewerten, deren Ergebnisse für dessen Vorankommen in der Universität wichtig sind. Im Januar 2016, kurz nachdem sie an der Universität in Eindhoven abgelehnt wird, beteiligt sich Isis Agora Lovecruft daran, Geschichten zu sammeln über Jacob Appelbaum.”
The person this is about is not an acquaintance of mine. I have no idea if they applied or didn't apply. The person I've spoken to --- am acquainted with (though not personal friends with) is Henry de Valence, who obviously did not lose a spot in Bernstein's lab to Appelbaum.
These are all incredibly creepy and inappropriate accusations for you to be making. They're also wildly against the site guidelines.
Henry de Valence is the person mentioned in that quote as having moved in next door to Appelbaum, as documented by djb:
https://eindhoven.cr.yp.to/false-statements-by-henry-de-vale...
No creepier than the way you're in every one of these threads argument-botting djb. The co-designer of ML-KEM can steelman DJB's point, despite his very personal involvement. Which causes folks to question why your reactions would be so much stronger than those of the directly involved. You blame folks for looking for reasons?
If you don't want people to question your motivations, don't behave like someone with questionable motivation. Seems simple.
[dead]
Can someone ELI5 what the issue is here? I feel like I'm missing a lot of nuance here. Are the NSA people attempting to weaken TLS by removing ECC?
No. This whole situation is extremely dumb.
Bernstein is a co-author on NIST PQC competition submissions that didn't win (Classic McEliece, which just had a huge new research result, and Streamlined NTRU Prime, a lattice cousin to MLKEM).
When CRYSTALS/Kyber was selected in the NIST competition instead of SNTRUP, Bernstein didn't take it well. He claimed malfeasance by NIST and sued them for allegedly hiding documents.
Meanwhile, over the subsequent years, the world has continued turning on its axes. CRYSTALS/Kyber is now ML-KEM. Because many cryptography engineers and other security people think there's a lot of urgency to getting PQC deployed (because of harvest-now decrypt-later [HNDL] attacks), the IETF got a move on standardizing hybrid ECDH/MLKEM TLS 1.3, which is what everyone uses.
Nobody at IETF has ever to my knowledge even hinted that anyone should avoid hybrids. There is a standards-track RFC defining ECDH/ML-KEM hybrids.
There are environments where hybrids are problematic. You won't likely use any of them ever. Some of them occur within the US Government, and some of them are on highly constrained platforms (people seem to disbelieve this is ever really a thing but I once gameovered a smart meter because its RF protocol only had like 16 bits of counter space for CTR).
Because of this, there is also a proposed informational RFC --- not a standards track document --- that documents what pure MLKEM looks like in a TLS 1.3 setting. Bernstein's entire argument is that this is an NSA plot.
> Because of this, there is also a proposed informational RFC --- not a standards track document --- that documents what pure MLKEM looks like in a TLS 1.3 setting.
For discussion on Bernstein's objection to that IETF draft see article from ~month ago, "NSA and IETF: Fairness":
* https://news.ycombinator.com/item?id=48811887
RFCs are used by developers as strict guidelines for implementation.
The mere publishing of an RFC has customarily been treated by developers as a stamp of approval from the IETF.
The NSA, contractors and their fans argue that simply adding a "RECOMMENDED=N" in an obscure section of this draft will somehow prevent said implementations in deployments.
However, as an example, Canada's NSA equivalent specifically requested the draft to be published so that they can use it to support their poor choice in deployment of solo ML-KEM nation-wide.
While ML-KEM may be sound, significant bugs in implementations in the wild continue to be published.
To be clear, CRQCs do not exist today.
ECC is battle tested, proven, and is used today.
It makes no sense to delete working cryptography and replace it with potentially buggy, non-battle tested implementations of new cryptography for a threat that does not yet exist today.
Instead, you fight HNDL [1] with hybrid which preserves the safety of today, and hopefully also, tomorrow.
No serious security person should be recommending otherwise which is, perhaps, why some may question the motives of those that are pushing for solo ML-KEM.
[1] Harvest now decrypt later
It's never been clear to me why NSA's "blue team" directorates haven't been spun off into a separate agency. Sure, NSA strengthened the S-boxes in DES and SHA-1 but from the outside there's no way to know whether they're making DES stronger against differential cryptanalysis or whether they're introducing a DUAL_EC-style vulnerability.
I'm sure there's a game-theoretic optimum choice when it comes to accepting proposals from the NSA vs rejecting them out of hand, but I'm not sure what that optimal choice is.
The purpose of a system is what it does.
https://archive.nytimes.com/www.nytimes.com/interactive/2013...
Imo "the optimal choice" is to be extremely skeptical to what comes to NSA proposing anything related to encryption/cryptography. From the first part of this blog series by DJB[1]:
> Try to put yourself in the mindset of NSA as an attacker. You have a massive budget to "covertly influence and/or overtly leverage" systems to "make the systems in question exploitable"; "to the consumer and other adversaries, however, the systems' security remains intact". One of your action items is to "influence policies, standards and specification for commercial public key technologies". Another is to "shape the worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS".
And when you read the Snowden docs and you come across to things like this 2010 GCHQ presentation[2], stating "for the past decade, NSA has lead an aggressive, multipronged effort to break widely used Internet encryption technologies" such as "SSL" and "SSH" and "VPNs"; that "cryptanalytic capabilities are now coming on line"; and that "vast amounts of encrypted Internet data which have up till now been discarded are now exploitable."
So we have these agencies like NSA and GCHQ, with stated, funded programs to make deployed cryptography exploitable (and historical evidence of them successfully doing just that)... It's an unbelievable conflict of interest for them to hold any role where they can shape what gets deployed. Absolutely bonkers.
And on DES specifically, it was both at once, not a binary. NSA in secret pushed IBM to cut the key size, while strengthening the algo against every attack except brute force. The design criteria were classified and IBM's own research docs were literally locked up under gov classification at NSA's request meanwhile when IBM personnel publicly denied any NSA involvement (and the NSA director publicly denied any algo weakening, again, a lie). So DES came out genuinely hardened against differential cryptanalysis but at the same time breakable by brute force by organizations with budgets like NSA's, by NSA's request/order.
For the "blue team" thing.. I guess it's actually better for them tactically to not spin off, because being NSA gives you authority in those circles. Standards bodies don't seem to treat the conflict of interest as a problem (as we can see), but rather as a qualification ("people who know cryptography best").
1: https://blog.cr.yp.to/20251004-weakened.html 2: https://web.archive.org/web/20240420184725if_/https://cdn.pr...
I thought this was going to be rehashing of the old NULL-cypher IPsec thread, but it’s a different thing.
Maybe we should treat standards like we do a free market - let anyone implement what they choose then let people chose which to adopt, but the main thing is get government out of the entire process.
If the government wants to standardise, that’s fine… just don’t make it an industry standard adopted by civilians. Let them have their weakened protocols will the market moves on
> I'm happy to report that 82 people spoke up on the TLS mailing list in unambiguous opposition to this spec during the voting period
How many of them spoke before on this mailing list, in any capacity what so ever? I suspect this is 99% people who showed up because you organized a brigadging, because you incited people and told them to show up and be completely outraged.
There's a >0% chance that DJB could be correct that there is some risk to this spec (which notably is not seeking recommendation status! So WTF?) The people approving and wanting this aren't fools, aren't lackies, aren't some great foe. There's little real opposition? Making up ghosts and enemies lurking in every corner, brigading people to show up in IETF meetings, who have never participated before, just to spread heat and anger you've programmed them for, is ignoble & indecent.
All too recently: https://news.ycombinator.com/item?id=48760490 https://news.ycombinator.com/item?id=48811887
> which notably is not seeking recommendation status!
I don’t have a dog in this fight, but some extremely important RFCs are only on the “informational” track. RFCs 1945 (HTTP 1.0), 4627 (JSON), 2818 (HTTPS), etc.
HTTP, JSON, and HTTPS all have standards-track RFCs.
As far as I know HTTP 1.0 doesn't have a standards-track RFC (HTTP 1.1 and later do). JSON and HTTPS do indeed have standards-track RFCs, but I stand by my original wording that their first informational RFCs were "extremely important."
because the NSA has never surreptitiously pushed bad standards they used to exploit before
/s
Which PQC standard are you suggesting they pushed, and how did they push it? Flesh the argument out.
That’s a very unfair position to take when dealing with secret agencies who try very hard to obfuscate this stuff - it is hard to provide evidence for in the moment.
The government has intentionally acted to weaken DES, standardized Dual_EC_DRBG, performed subtle subterfuge through interfering how NIST operates to inject weaknesses and vulnerabilities, trying to weaken SSL and IPSec, 4G smartphone encryption.
These are all documented examples of the NSA engaging in bad faith. So whether or not it is happening in this particular case, there’s now just zero trust in the institutions acting in good faith. And given it took decades for the actions to come out after they were taken, how do you expect someone to answer your request to present evidence there’s anything nefarious happening now?
Anyway, that’s what I think a fleshed out argument would look like
It's a simple question. I'm not asking anybody to prove anything. I'm literally asking: propose the PQC standard IETF could have subverted, and give a sketch of how they could have done it. The bar is merely "plausibility". I'm not asking whether NSA has subverted standards before; obviously they have.
NSA, by the way, rescued DES from differential cryptography, the core mechanism by which block ciphers and hash functions have been attacked ever since.
They did both - they strengthened it from differential integrity but weakened it by picking a known-to-be-too-short key length. Meaning they had the compute power to crack it but others couldn’t do the same through pure algorithmic means.
As for your post below
> it can't be that NSA simply knows a vulnerability that impacts one very specific lattice scheme and not the others
Ok. My argument is they know all lattice schemes are weak and the push to use a lattice-only scheme is precisely to have a cryptographic mechanism they can easily bypass without a classical known-secure backstop.
See, here's another argument that doesn't work here, because Bernstein very publicly backs a different lattice cryptography scheme.
In addition to the previously-stated reason why that argument is inoperative (besides being unfalsifiable, it admits a strategy where NSA "poisons the well" to get people to avoid a particular construction or family of algorithms, so that we all move to weaker ones --- a counterfactual that should be much more vivid after what was released this week!)
> NSA, by the way, rescued DES from differential cryptography, the core mechanism by which block ciphers and hash functions have been attacked ever since
That's why you use ML-KEM 1024 at all... As part of a hybrid.
I don't know what this is, but it isn't an answer to the question. I'm starting to notice that nobody is able to come up with an answer.
There is no public reason to think that 1024 is better than 768, or DJB's S-NTRU-P 761. The NSA might know something, but we can't trust them. So, use a hybrid, in case they are really just trying to protect us.
That can't be the argument --- it can't be that NSA simply knows a vulnerability that impacts one very specific lattice scheme and not the others. The reason for that is a cryptographic concept known as the Vizzini Conjecture: the argument you just put forward can be applied to literally any cryptographic standard NIST authors. Since NSA knows that, and knows you know it, you can clearly not choose the wine in front of you. It must be that the standard NIST picks is the only secure one, so that NSA can see it tainted by NIST association.
But yes, this is the useful conversation to have. There are other scenarios! You can get into more detail on where MLKEM came from, for instance.
Yes, they trick me and I pick the poisoned wine... But wait, no, I used a hybrid. Imagine the code can't be backdoored (it's proven not to crash/be slow/be exploitable) so at worst it can make the security no better. At best, the NSA knows a whole new subfield of cryptography (from history: differential cryptanalysis) and it really is more secure.
They laugh at us while we try to think of how 1024 is better than 768: "bigger is better, right?" "does 1024 refer to the number of years it takes Nightmare Moon to break the code?"
There is nobody at IETF saying you shouldn't use a hybrid! In fact, it's the exact opposite: hybrid ECDH/MLKEM is a standards-track RFC, and the proposed pure-MLKEM RFC is not, nor is it "Recommended" (in IETF parlance).
Let's keep the thread coherent: the original claim, by cryptographer 'cassonmars, is that the issue here is NSA pushing bad standards. It's not "hybrid vs. pure", which is a non-issue. All I asked for was a plausible story about how NSA might have pushed a bad PQC standard.
> Let's keep the thread coherent: the original claim
How do you save your poisoned wine? A hybrid with 1024 is made less trustworthy if the NSA pushes 1024 alone, since then we know that they want customers to use 1024 alone, which is what they would want if it was weak. But they know that we would know that, so if they really want to help us they should withdraw the draft. If it was strong but we know why, they shouldn't want to make us doubt ourselves. If it is strong (and 512 and 768 are not) they can't tell us, and can only subtly point to their own double encryption and security level documents. The only move that can cover all the cases is a hybrid with 1024, so this draft is a bad standard.
No, the original claim was by me. And I gave you a plausible story. You just didn’t want to hear it.
https://news.ycombinator.com/item?id=48820336
This is a link to a comment from 38 days ago.
Re "NSA rescued DES from differential cryptography":
I coined the name Deep Crack for the EFF machine that brute-forced DES in 56 hours on a $250K budget. Ostensibly a play on Deep Blue and Deep Thought. The official hidden message, per my email in 1998: there's a Deep Crack in the government's export control policies. Unofficial hidden message: they strengthened DES against every attack except the one their budget could afford.
Not responsible for allusions to the Liberty Bell, Marion Barry's favorite nose candy, Mark Felt's alias, Linda Lovelace's famous movie, or Douglas Adams's computer that answered forty-two. Responsible for the observation that when someone says NSA "rescued" a standard, it's worth asking what crack they left in it for themselves.
The first key's free!
Deep Crack origin story (Denise Caruso + Gilmore + Hopkins, 1998):
https://www.donhopkins.com/home/archive/humor/deep-crack.txt
EFF DES cracker:
https://en.wikipedia.org/wiki/EFF_DES_cracker
Deep Crack Chip:
https://en.wikipedia.org/wiki/EFF_DES_cracker#/media/File:Ch...
EFF's Cracking DES Page:
https://w2.eff.org/Privacy/Crypto/Crypto_misc/DESCracker/
Sun DES chip socket (export control) and boot ROM easter egg:
https://news.ycombinator.com/item?id=34125377
Brings to mind this lovely quote from the Snowden documents:
“The road to developing this standard was smooth once the journey began... However, beginning the journey was a challenge in finesse ... After some behind-the-scenes finessing with the head of the Canadian national delegation and with C.S.E., the stage was set for N.S.A. to submit a rewrite of the draft ... Eventually, N.S.A. became the sole editor.”
https://macleans.ca/society/technology/nsa-says-it-finessed-...