Live data from Hacker News

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

blog.cr.yp.to

11–20 of 249 posts

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

#11

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 for everyone else... but eventually word got out that it's almost certainly an NSA NOBUS special, and everyone started disabling it.

Knowing all that, and planning for a future where quantum computers might defeat ECC -- it's not defeated yet, and nobody knows when in the future that might happen... would you choose:

Option A): encrypt key exchange with ECC and the new unproven algorithm

Option B): throw out ECC and just use the new unproven algorithm

NIST tells you option B is for the best. NIST told you to use Dual_EC_DRBG. W3C adopted EME at the behest of Microsoft, Google and Netflix. Microsoft told you OOXML is a valid international standard you should use instead of OpenDocument (and it just so happens that only one piece of software, made by Microsoft, correctly reads and writes OOXML). So it goes on. Standards organisations are very easily corruptable when its members are allowed to have conflicts of interest and politick and rules-lawyer the organisation into adopting their pet standards.

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

#13
post #6

[flagged]

That's not what the message you linked claims at all. Maybe you missed the "in this message" at the end of the sentence?

No not really - I don’t think choosing to post from an alternative email removes the association issue that the original intent is trying to capture.

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

#15
post #7

Earlier quoted context omitted.

”No association” and “I am not a representative” are quite different things to say.

[flagged]

An employee doesn’t act as an official representative of their employer nor do they speak for the employee in any official capacity. That is what the message says.

The informal also didn’t cloak their identity (implies some malicious intent), they simple did not use their work email. Nothing wrong with that.

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

#16
post #7

Earlier quoted context omitted.

”No association” and “I am not a representative” are quite different things to say.

[flagged]

I’m sorry, can you state which organization you are speaking for with this comment? It wasn’t immediately clear.

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

#20
post #14

20+2 (conditional support) versus 7. 22/29 = 76% in some form of "yea" That feels like "rough consensus"

The standard used in the C and C++ committees is essentially a 2-to-1 majority in favor. I'm not aware of any committee where a 3-to-1 majority is insufficient to get an item to pass.

DJB's argument that this isn't good enough would, by itself, be enough for me to route his objections to /dev/null; it's so tedious and snipey that it sours the quality of his other arguments by mere association. And overall, it gives the impression of someone who is more interested in derailing the entire process than in actually trying to craft a good standard.

Post reply on HN