Earlier quoted context omitted.
To extend on this good point-- 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 the…
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.
NSA and IETF: Fairness
71–80 of 198 posts
Re: NSA and IETF: Fairness
#72The two most important things to understand about this kerfuffle: (1) MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe; their submission, Kyber, was selected in an open competition in which Bernstein himself submitted a closely-related algorithm (and then contested the result, suing NIST for documents to cla…
You are simplifying ad absurdum. The NSA is as likely to compromise hash and signing algorithms as the police are likely to recommend pissing in petri dishes to cast doubt on that troublesome forensic science. The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber. Estimates at one point were that they had more than half of appropriate PhD level Math…
Re: NSA and IETF: Fairness
#73Earlier quoted context omitted.
You are simplifying ad absurdum. The NSA is as likely to compromise hash and signing algorithms as the police are likely to recommend pissing in petri dishes to cast doubt on that troublesome forensic science. The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber. Estimates at one point were that they had more than half of appropriate PhD level Math…
The NSA had nothing to do with designing Kyber.
Re: NSA and IETF: Fairness
#74Earlier quoted context omitted.
To extend on this good point-- 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 the…
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.
For most users however, side channel resistance is a very important property that shouldn't be considered an optional after-thought. If standards bodies made it mandatory to consider side channel resistance when standardising cryptography schemes, the choice of what scheme(s) to standardise could look quite different, and thus general use of cryptography would have improved security by default. If some types of users don't care about side channel resistance, then great, make use of non-side-channel-resistant cryptography optional for them to use. Don't standardise it the other way around.
For example:
FIPS 186-5 sB.1 states: "Other (constant time) algorithms that produce an equivalent result may be used."[1]
NIST SP 800-186 sE.4 states: "If one is concerned about side-channel leakage, one should compute the inverse using a constant-time algorithm."[2]
RFC 8032 s8.1 states: "Note that the example implementations in this document do not attempt to be side-channel silent."[3]
A better standard may, for example, _require_ [4] be implemented in order for an implementation to claim conformance with the standard. Not as an optional after-thought. If there are users wanting to trade off side channel resistance for performance gains, then write a new standard to that effect and remove the requirement to implement [4].
A better standardisation process may, for example, only accept candidate algorithms _if_ they are side channel resistant. This opens up the standard to as many use cases as possible. No cutting corners to pretend performance is better for one implementation because it trades off side channel resistance for performance, and no pretending side channel sensitive use cases don't exist.
[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf
[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1
[4] https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplic...
Re: NSA and IETF: Fairness
#75Earlier quoted context omitted.
Sadly, a similar myth/fallacy persists about the Wikipedia consensus process (at least the English project and others deriving policy from it.) Participants in disputes and RFCs literally call their comments “!vote” in true hacker notation, to repeatedly and clearly emphasize that “vote count” is never a factor in the process of establishing consensus. (Elections are, however, regularly held, and votes counted, for p…
From the way DJB talks about IETF processes, it's quite clear to me though that he has little trust/belief in the IETF consensus process. I thought he said as much somewhere but can't find that right now. (It's particularly obvious in https://blog.cr.yp.to/20260405-votes.html ) Which is why I'm noting the alienation of "IETF believers", which I should maybe clarify I count myself as. The IETF is a lot of people doing…
The gist of it is that standards organizations like the IETF depend on a specific carve-out in US antitrust law (in order for it to be legal for American companies like Cisco and Google to participate in them), and that carve-out includes a specific definition of what "standards organizations" and "consensus" are. So even if the IETF uses different words to describe its processes, those processes still have to comply with the legal definition that separates a "standards organization" from, like, an illegal cartel.
Re: NSA and IETF: Fairness
#76Earlier quoted context omitted.
If it's supported it will be used, e.g. by vendors which decide for some reason to use it Null encryption used to be supported as well, and no one was forced to use it. But when something insecure is supported by a protocol it will lead to security hiccups. If it's dangerous it shouldn't be supported.
But that’s not what the IETF is. They don’t police, they encourage collaboration and standardization between implementers.
I recall the early-to-mid-90s when the IETF was a powerhouse, churning out foundational standards and documents monthly, and every time I read a foundational RFC for some protocol I wanted to learn, the "Security Considerations" section was intentionally left completely blank and un-considered.
I don't know if it was recklessness or expediency or a very calculated tactic (the Internet was invented by DARPA, after all) but Internet protocols were so ridiculously insecure, and based on absurd trust models that were repeatedly broken, and everything always transmitted in plaintext (because, of course, all networks were physically wired, secured, and only the good guys could tap into them).
It was an absolute Wild West clown college as the Internet transitioned to commercial and privatized use cases, and I suppose it guaranteed job security for generations of cybersecurity experts and cryptographers.
Re: NSA and IETF: Fairness
#77Earlier quoted context omitted.
The NSA had nothing to do with designing Kyber.
He didnt say it did, he said "The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber"
Re: NSA and IETF: Fairness
#78Earlier quoted context omitted.
> there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document “People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t. (There are co…
These are arguments, but I don't really understand what they're arguments for. At issue here is whether or not the IETF should document usage of pure-MLKEM TLS. There are environments where people are going to use pure-MLKEM TLS, whether Bernstein likes it or not. His argument is that the IETF should pretend that isn't happening, and throw up weird procedural obstacles to it.
Re: NSA and IETF: Fairness
#79The two most important things to understand about this kerfuffle: (1) MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe; their submission, Kyber, was selected in an open competition in which Bernstein himself submitted a closely-related algorithm (and then contested the result, suing NIST for documents to cla…
I was happy to see the lead of Europe’s PQC team also voted with the cryptographers.
Re: NSA and IETF: Fairness
#80The two most important things to understand about this kerfuffle: (1) MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe; their submission, Kyber, was selected in an open competition in which Bernstein himself submitted a closely-related algorithm (and then contested the result, suing NIST for documents to cla…
The optionality of MLKEM by itself is of a similar shape to standardizing a lame DRBG that 'obviously' no one would use and anyone who would use would use the appendix parameter generation scheme that would have rendered it secure (although still slow). The reality of it was that once it was standardized NSA was able to secretly compel its use.
On one hand MLKEM by itself seems like a better choice than DUAL-EC, on the other hand that fact should make it much easier for a powerful attacker to cause a target to use it if you do have an attack that exploits this fact.
MLKEM was selected out of myriad other options through a NIST process which was directly influenced by NSA (including in manners that NIST failed to disclose and actively mislead the group about). I think this makes the commentary regarding NSA highly relevant. While it seems less like that NSA already knows of a total break in MLKEM (and indeed their influence could have been in a strengthening direction...) it's possible that their influence was motivated by things like that ease of undetectably compromising specific implementations through techniques like dopant adulteration or specialized side channel weaknesses.
If your plan it to tamper with chip mfgr or hit them with a very well aimed e-beam (e.g. to cause ion migration) after the fact then having a non-hybrid scheme is pretty obviously going to make your life much easier... Or perhaps they've taken a route similar to the one they took with Crypto AG-- this time positioning themselves as a fabless silicon vendor to sell MLKEM RTL to a market that doesn't have an implementation but already has many robust ECC implementations to choose from.
...and that's without getting into the unknown possibility of a cryptoanalytic breakthrough.
I don't think it's even safe to say that NSA would only consider NOBUS backdoors-- I don't think any of us can know how inadvisably arrogant the relevant decision makers may be and what they might consider NOBUS. Given how DUAL_EC went in Netscreen's products I think it's reasonable to argument that there is no such thing as a NOBUS backdoor when push comes to shove. Capping DES's key size is candidate example of a very much non-NOBUS weakness that NSA felt comfortable with, as one needed a particularly amount of strength to exploit it which they believed that only they had. Today, of course, a child's video game device can crack DES as a direct product of that part of their influence.
Not a great track record when fear of "store and decrypt later" attacks is much of what motivates the use of PQ key agreement today.
The consistent aggression five-eyes affiliated cryptographic-intelligence groups have had for hybrid schemes is truly difficult to comprehend-- given that practically everyone else considers them obviously prudent in all cases where the resource costs permit -- and I think this justifies the utmost concern and caution. And in terms of caution hybrid schemes are table stakes.
A major theme of DJB's cryptographic security advocacy is that cryptographic security is often as much about what you don't offer as it is what you do. A completently engineered security product is misuse resistant and it's not completely clear to me that a standard which offers the choice of a non-hybrid mlkem qualifies as misuse resistant.
That said, there are plenty of drafts that are in no way misuse resistant. :)