Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.cr.yp.to

Post reply on HN
Print view View original

211–220 of 249 posts

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

#211

Post by tptacek »

cryptonector wrote: post #204
dataflow wrote: post #72

Earlier quoted context omitted.

> One other factor which comes in to play, some people can't stand his communication style. When disagreed with, he tends to dig in his heels and write lengthly responses that question people's motives, like in this blog post and others. I don't have context on this other than the linked page, but if what he's saying is accurate, it does seem pretty damning and corrupt, no? Why all the lies and distortions otherwise…

> I don't have context on this other than the linked page, but if what he's saying is accurate, it does seem pretty damning and corrupt, no? It's complicated. You'd have to know the rules and read the list archives, and make up your own mind. DJB might be overselling it, so you really do have to check it yourself. I think the WG chair had enough cover to make the call they made. What _I_ would have done is do a WG co…

To which "underlying controversial question" are you referring?

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

#212

Post by johncolanduoni »

tptacek wrote: post #210
johncolanduoni wrote: post #206

Earlier quoted context omitted.

I mean have a bunch of competent teams that (importantly) didn’t design the algorithm read the final draft and write their versions of it. Then they and others can perform practical analysis on each (empirically look for timing side channels on x86 and ARM, fuzz them, etc.). > If instead you mean "figure out after some period of implementation whether the standard itself is good", I don't know how that's meant to be…

Again: that has now happened. What have we learned from it that we needed to know 3 years ago when NIST chose Kyber? That's an important question, because this is a whole giant thread about Bernstein's allegation that the IETF is in the pocket of the NSA (see "part 4" of this series for that charming claim). Further, the people involved in the NIST PQ key establishment competition are a murderers row of serious crypt…

I don’t think IETF is in the pocket of the NSA. I really wish the US government hadn’t hassled Bernstein so much when he was a grad student, it would make his stuff way more focused on technical details and readable without rolling your eyes.

> Further, the people involved in the NIST PQ key establishment competition are a murderers row of serious cryptographers and cryptography engineers.

That’s actually my point! When you’re trying to figure out if your standard is difficult to implement correctly, that everyone who worked on the reference implementations is a genius who understands it perfectly is a disadvantage for finding certain problems. It’s classic expert blindness, like you see with C++ where the people working on the standard understand the language so completely they can’t even conceive of what will happen when it’s in the hands of someone that doesn’t sleep with the C++ standard under their pillow.

Like, would anyone who developed ECC algorithms have forgotten to check for invalid curve points when writing an implementation? Meanwhile among mere mortals that’s happened over and over again.

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

#213

Post by tptacek »

johncolanduoni wrote: post #212
tptacek wrote: post #210

Earlier quoted context omitted.

Again: that has now happened. What have we learned from it that we needed to know 3 years ago when NIST chose Kyber? That's an important question, because this is a whole giant thread about Bernstein's allegation that the IETF is in the pocket of the NSA (see "part 4" of this series for that charming claim). Further, the people involved in the NIST PQ key establishment competition are a murderers row of serious crypt…

I don’t think IETF is in the pocket of the NSA. I really wish the US government hadn’t hassled Bernstein so much when he was a grad student, it would make his stuff way more focused on technical details and readable without rolling your eyes. > Further, the people involved in the NIST PQ key establishment competition are a murderers row of serious cryptographers and cryptography engineers. That’s actually my point! W…

I don't think this has much of anything to do with Bernstein's qualms with the US government. For all his concerns about NIST process, he himself had his name on a NIST PQC candidate. Moreover, he's gotten into similar spats elsewhere. This isn't even the first time he's gotten into a heap of shit at IETF/IRTF. This springs to mind:

https://mailarchive.ietf.org/arch/msg/cfrg/qqrtZnjV1oTBHtvZ1...

This wasn't about NSA or the USG! Note the date. Of course, had this happened in 2025, we'd all know about it, because he'd have blogged it.

But I want to circle back to the point I just made: you've said that we'd all be better off if there was a burning-in period for implementors before standards were ratified. We've definitely burnt in MLKEM now! What would we have done differently knowing what we now know?

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

#214

Post by johncolanduoni »

tptacek wrote: post #213
johncolanduoni wrote: post #212

Earlier quoted context omitted.

I don’t think IETF is in the pocket of the NSA. I really wish the US government hadn’t hassled Bernstein so much when he was a grad student, it would make his stuff way more focused on technical details and readable without rolling your eyes. > Further, the people involved in the NIST PQ key establishment competition are a murderers row of serious cryptographers and cryptography engineers. That’s actually my point! W…

I don't think this has much of anything to do with Bernstein's qualms with the US government. For all his concerns about NIST process, he himself had his name on a NIST PQC candidate. Moreover, he's gotten into similar spats elsewhere. This isn't even the first time he's gotten into a heap of shit at IETF/IRTF. This springs to mind: https://mailarchive.ietf.org/arch/msg/cfrg/qqrtZnjV1oTBHtvZ1... This wasn't about NSA…

> What would we have done differently knowing what we now know?

With the MLKEM standard? Probably nothing, Bernstein would have done less rambling in these blog posts if he was aware of something specifically wrong with one of the implementations. My key point here was that establishing an implementation phase during standardization is not an incoherent or categorically unjustifiable idea, whether it makes sense for massive cryptographic development efforts or not. I will note that something not getting caught by a potential process change is a datapoint that it’s not needed, but isn’t dispositive.

I do think there is some baby in the Bernstein bathwater that is this blog post series though. His strongest specific point in these posts was that the TLS working group adding a cipher suite with a MLKEM-only key exchange this early is an own goal (but that’s of course not the fault of the MLKEM standard itself). That’s an obvious footgun, and I’ll miss the days when you could enable all the standard TLS 1.3 cipher suites and not stress about it. The arguments to keep it in are legitimately not good, but in the area director’s defense we’re all guilty of motivated reasoning when you’re talking to someone who will inevitably accuse you of colluding with the NSA to bring about 1984.

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

#215

Post by AnthonyMouse »

ants_everywhere wrote: post #105
seethishat wrote: post #10

For context, djb has been doing and saying these things since he was a college student: While a graduate student at the University of California at Berkeley, Bernstein completed the development of an encryption equation (an "algorithm") he calls "Snuffle." Bernstein wishes to publish a) the algorithm (b) a mathematical paper describing and explaining the algorithm and (c) the "source code" for a computer program that…

That was when he had the legal expertise of the EFF to help him make his case. Later he decided to represent himself in court and failed > This time, he chose to represent himself, although he had no formal legal training. On October 15, 2003, almost nine years after Bernstein first brought the case, the judge dismissed it.... https://en.wikipedia.org/wiki/Bernstein_v._United_States

> Later he decided to represent himself in court and failed

To be more specific, the government broke out their get out of court free card and claimed they weren't threatening to prosecute him even though they created a rule he was intending to violate. It's a dirty trick the government uses when they're afraid you're going to win so they can get the case dismissed without the court making a ruling.

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

#216

Post by tptacek »

johncolanduoni wrote: post #214
tptacek wrote: post #213

Earlier quoted context omitted.

I don't think this has much of anything to do with Bernstein's qualms with the US government. For all his concerns about NIST process, he himself had his name on a NIST PQC candidate. Moreover, he's gotten into similar spats elsewhere. This isn't even the first time he's gotten into a heap of shit at IETF/IRTF. This springs to mind: https://mailarchive.ietf.org/arch/msg/cfrg/qqrtZnjV1oTBHtvZ1... This wasn't about NSA…

> What would we have done differently knowing what we now know? With the MLKEM standard? Probably nothing, Bernstein would have done less rambling in these blog posts if he was aware of something specifically wrong with one of the implementations. My key point here was that establishing an implementation phase during standardization is not an incoherent or categorically unjustifiable idea, whether it makes sense for…

In what way is adding an MLKEM-only code point an "own goal"? Exercise for the reader: find the place where Bernstein proposed we have hybrid RSA/ECDH ciphersuites.

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

#217

Post by cryptonector »

ants_everywhere wrote: post #3

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…

> I don't know if this is just how DJB writes,

He's caustic, but often right.

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

#219

Post by tptacek »

amiga386 wrote: post #11
ants_everywhere wrote: post #3

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…

LWE cryptography is probably better understood now than ECDH was in 2005, when Bernstein published Curve25519, but I think you'll have a hard time finding where Bernstein recommended hybrid RSA/ECDH key exchanges.

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

#220

Post by zahllos »

cryptonector wrote: post #189
zahllos wrote: 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…

You're not accurately representing DJB's concern. His concern is that NSA will get vendors to ship code that will prefer ML-KEM, which, not being a hybrid of ECC and PQC, will be highly vulnerable should ML-KEM turn out to be weak, and then there's the concern that it might be backdoored -- that this is a Dual_EC redux.

I understand his concern perfectly. What I am saying is that his concern is not mitigated at all by the presence or absence of an IETF standard.

This is going to happen anyway (non hybrid) at least inside USG because that's what NSA want.

Post reply on HN