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.
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!
tptacek once adored djb. This changed around 2015-2016, when one of tptacek’s crypto acquaintances lost a grad school spot (studying under djb) to Jacob Appelbaum. This led her and a couple of her friends to accuse Appelbaum of sexual assault and grape.
tptacek wants to be seen as a good feminist ally because his feminist wife would castrate him otherwise. So, he #BelievedWomen, and part of that is making sure you shun the unbelievers. Thus, djb is to be criticized by tptacek at every opportunity.
“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.
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
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.
> 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.
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.
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!
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.
tptacek once adored djb. This changed around 2015-2016, when one of tptacek’s crypto acquaintances lost a grad school spot (studying under djb) to Jacob Appelbaum. This led her and a couple of her friends to accuse Appelbaum of sexual assault and grape.
tptacek wants to be seen as a good feminist ally because his feminist wife would castrate him otherwise. So, he #BelievedWomen, and part of that is making sure you shun the unbelievers. Thus, djb is to be criticized by tptacek at every opportunity.
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.
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.
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...
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.
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
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...
> 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.
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.
> 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.
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-...