Live data from Hacker News

NSA and IETF, part 3: Dodging the issues at hand

blog.cr.yp.to

21–30 of 249 posts

Re: NSA and IETF, part 3: Dodging the issues at hand

#21
Amongst the numerous reasons why you _don't_ want to rush into implementing new algorithms is even the _reference implementation_ (and most other early implementations) for Kyber/ML-KEM included multiple timing side channel vulnerabilities that allowed for key recovery.[1][2]

djb has been consistent in view for decades that cryptography standards need to consider the foolproofness of implementation so that a minor implementation mistake specific to timing of specific instructions on specific CPU architectures, or specific compiler optimisations, etc doesn't break the implementation. See for example the many problems of NIST P-224/P-256/P-384 ECC curves which djb has been instrumental in fixing through widespread deployment of X25519.[3][4][5]

[1] https://cryspen.com/post/ml-kem-implementation/

[2] https://kyberslash.cr.yp.to/faq.html / https://kyberslash.cr.yp.to/libraries.html

[3] https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplic...

[4] https://safecurves.cr.yp.to/ladder.html

[5] https://cr.yp.to/newelliptic/nistecc-20160106.pdf

Re: NSA and IETF, part 3: Dodging the issues at hand

#22

Earlier quoted context omitted.

He’s smart and prolific, for sure, but I lost respect for him several years ago.

Why, if I might respectfully ask?

Sure! First, while I’m in no position to judge cryptographic algorithms, the success of cha-cha and 25519 speak for themselves. More prosaically, patriecia/critbit trees and his other tools are the right thing, and foresighted. He’s not just smart, but also prolific.

However, he’s left a wake of combative controversy his entire career, of the “crackpot” type the parent comment notes, and at some point it’d be worth his asking, AITA? Second, his unconditional support of Jacob Appelbaum has been bonkers. He’s obviously smart and uncompromising but, despite having been in the right on some issues, his scorched earth approach/lack of judgment seems to have turned his paranoia about everyone being out to get him into a self-fulfilling prophecy.

Re: NSA and IETF, part 3: Dodging the issues at hand

#23

D. J. Bernstein is very well respected and for very good reason. And I don't have firsthand knowledge of the background here, but the blog posts about the incident have been written in a kind of weird voice that make me feel like I'm reading about the US Government suppressing evidence of Bigfoot or something. Stuff like this > Wow, look at that: "due process".... Could it possibly be that the people writing the law…

It's very simple. ECC is well understood and has not been broken over many years. ML-KEM is new, and hasn't had the same scrutiny as ECC. It's possible that the NSA already knows how to break this, and has chosen not to tell us, and NIST plays the useful idiot. NIST has played the useful idiot before, when it promoted Dual_EC_DRBG, and the US government paid RSA to make it the default CSPRNG in their crypto libraries…

Thank you, that seems to be the whole ball game for me right there. I understood the sarcastic tone as kind of exasperation, but it means something in the context of an extremely concerning attempt to ram through a questionable algorithm that is not well understood and risks a version of an NSA backdoor, and the only real protection would be integrity of standards adoptions processes like this one. You've really got to stick with the substance over the tone to be able to follow the ball here. Everyone was losing their minds over GDPR introducing a potential back door to encrypted chat apps that security agencies could access. This goes to the exact same category of concern, and as you note it has precedent!

So yeah, NSA potentially sneaking a backdoor into an approved standard is pretty outrageous, and worth objecting to in strongest terms, and when that risk is present it should be subjected to the highest conceiveable standard of scrutiny.

In fact, I found this to be the strongest point in the article - there's any number of alternatives that might (1) prove easier to implement, (2) prove more resilient to future attacks (3) turn out to be the most efficient.

Just because you want to do something in the future doesn't mean it needs to be ML-KEM specifically, and the idea of throwing out ECC is almost completely inexplicable unless you're the NSA and you can't break it and you're trying to propose a new standard that doesn't include it.

How is that not a hair on fire level concern?

Re: NSA and IETF, part 3: Dodging the issues at hand

#24
In context, this particular issue is that DJB disagrees with the IETF publishing an ML-KEM only standard for key exchange.

Here's the thing. The existence of a standard does not mean we need to use it for most of the internet. There will also be hybrid standards, and most of the rest of us can simply ignore the existence of ML-KEM -only. However, NSA's CNSA 2.0 (commercial cryptography you can sell to the US Federal Government) does not envisage using hybrid schemes. So there's some sense in having a standard for that purpose. Better developed through the IETF than forced on browser vendors directly by the US, I think. There was rough consensus to do this. Should we have a single-cipher kex standard for HQC too? I'd argue yes, and no the NSA don't propose to use it (unless they updated CNSA).

The requirement of the NIST competition is that all standardized algorithms are both classical and PQ-resistant. Some have said in this thread that lattice crypto is relatively new, but it actually has quite some history, going back to Atjai in '97. If you want paranoia, there's always code theory based schemes going back to around '75. We don't know what we don't know, which is why there's HQC (code based) waiting on standardisation and an additional on-ramp for signatures, plus the expensive (size and sometimes statefulness) of hash-based options. So there's some argument that single-cipher is fine, and we have a whole set of alternative options.

This particular overreaction appears to be yet another in a long running series of... disagreements with the entire NIST process, including "claims" around the security level of what we then called Kyber, insults to the NIST team's security level estimation in the form of suggesting they can't do basic arithmetic (given we can't factor anything bigger than 15 on a real quantum computer and we simply don't have hardware anywhere near breaking RSA, estimate is exactly what these are) and so on.

Re: NSA and IETF, part 3: Dodging the issues at hand

#26

Earlier quoted context omitted.

[flagged]

[flagged]

@dang, can we establish a rule that NSA apologists should not be doxxing HN members for the sin of advocating against the NSA's preferred narratives and worldview?

Deliberate personal breaches of privacy against HN members as a response to the contents of their speech like this stifle free discourse to the highest degree possible and should be banned or at least harshly admonished, no?

Re: NSA and IETF, part 3: Dodging the issues at hand

#27
post #24

In context, this particular issue is that DJB disagrees with the IETF publishing an ML-KEM only standard for key exchange. Here's the thing. The existence of a standard does not mean we need to use it for most of the internet. There will also be hybrid standards, and most of the rest of us can simply ignore the existence of ML-KEM -only. However, NSA's CNSA 2.0 (commercial cryptography you can sell to the US Federal…

Except when the government starts then mandating a specific algorithm.

And yes. This has happened. There’s a reason there’s only the NIST P Curves in the WebPKI world.

Re: NSA and IETF, part 3: Dodging the issues at hand

#28

Earlier quoted context omitted.

[flagged]

@dang, can we establish a rule that NSA apologists should not be doxxing HN members for the sin of advocating against the NSA's preferred narratives and worldview? Deliberate personal breaches of privacy against HN members as a response to the contents of their speech like this stifle free discourse to the highest degree possible and should be banned or at least harshly admonished, no?

It's not really "doxing" when the public username they chose to use is their actual name, leading directly to their github profile, and their arguing that you always represent your employer, even if you "cloak" yourself in an alternate name.

Saying that it is a "breach of privacy" when the relevant details are being advertised by the person in question is silly.

Re: NSA and IETF, part 3: Dodging the issues at hand

#30
tl;dr DJB is trying to stop the NSA railroading bad crypto into TLS standards, the objections deadline is in two days, and they're stonewalling him

This /. story fills in the backstory: https://it.slashdot.org/story/25/11/23/226258/cryptologist-d...

  Normal practice in deploying post-quantum cryptography is to deploy ECC+PQ. IETF's TLS working group is standardizing ECC+PQ. But IETF management is also non-consensually ramming a particular NSA-driven document through the IETF process, a "non-hybrid" document that adds just PQ as another TLS option.
Post reply on HN