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

NSA and IETF: Fairness

blog.cr.yp.to

Post reply on HN
Print view View original

61–70 of 198 posts

Re: NSA and IETF: Fairness

#61

Post by yardstick »

ekr____ wrote: post #52
yardstick wrote: post #34

DJB has orchestrated a vote rigging campaign against this WGLC, encouraging users to join the list and vote/express their opinion and providing the exact subject header to use. Have any other sides been saying, essentially, just join the group and say you’re for/against? He’s been moderated during the last call because of his email disclaimer/footnote, and apparently refuses to respond on list during this time. Seems…

> What’s his next step if the authors publish as an information RFC? He can’t stop that, right? This is a slightly complicated question. There are several main routes to an Informational RFC. * Through the IETF Stream, either through the Working Group (what is happening now) or via sponsorship by an Area Director. The former is what is happening now (this document is not up for Proposed Standard). I don't think the l…

Thanks for the clarification. It’s a bit of a shame as going via ISE would have let the group move onto other endeavours. Maybe people will just refer to the draft name and that’s that.

Re: NSA and IETF: Fairness

#62

Post by lokar »

g-b-r wrote: post #33
throw0101d wrote: post #15

Earlier quoted context omitted.

> https://www.iana.org/assignments/tls-parameters/tls-paramete... Further the draft that this is all about does not make a recommendation for its use. The currently IETF-recommended TLS algorithms are: X25519MLKEM768, x448, x25519, secp384r1, secp256r1. As noted by someone on the IETF list [1] there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a s…

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.

Re: NSA and IETF: Fairness

#63

Post by g-b-r »

tptacek wrote: post #39
iririririr wrote: post #20

if i were the nsa, I'd have spent all my research money on attacking ecc+pq, because 1. no self respecting security engineer would deploy bare pq (see cloudflare), 2. no phd research team would attack the combination (well, not before until it's too late) because that's harder than a phd requires (they will target solo pq or solo ecc). 3. it's much easier to "sell". q.e.d. this article.

This is completely backwards. The more cryptography-literate you are, the more likely it is you think hybrids are silly. Plenty of cryptographers think this is all bullshit, and that ECC+MLKEM makes about as much sense as an AES+Serpent cascade. It is simultaneously the case that MLKEM is far less mysterious than programmers on message boards think it is, and that conventional ECC and finite field cryptography is muc…

> The more cryptography-literate you are, the more likely it is you think hybrids are silly

You are if you're considering a cypher that's extremely likely to be secure.

In this case we're ok to introduce something with a chance to be quantum-resistant before it's been studied enough, because we want a chance of being quantum-resistant soon.

But that's only ok if you add it to the existing, reliable, systems.

Were there not the issue of quantum computers we wouldn't even be considering to use different cyphers at this time.

Re: NSA and IETF: Fairness

#64

Post by g-b-r »

lokar wrote: post #62
g-b-r wrote: post #33

Earlier 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.

They publish what become standards, you can't just support any existing option in an encryption protocol (if you want to have a secure one).

Re: NSA and IETF: Fairness

#65

Post by g-b-r »

tptacek wrote: post #8

The 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…

> nothing that's happening here has really anything to do with NSA

How can you say that???

It seems to be literally only for their claim to need it that pure MLKEM is being requested..!

A summary at https://blog.cr.yp.to/20251004-weakened.html, or just see e.g. https://keymaterial.net/2025/11/27/ml-kem-mythbusting for an opposite voice stating the same...

Re: NSA and IETF: Fairness

#66

Post by tptacek »

g-b-r wrote: post #63
tptacek wrote: post #39

Earlier quoted context omitted.

This is completely backwards. The more cryptography-literate you are, the more likely it is you think hybrids are silly. Plenty of cryptographers think this is all bullshit, and that ECC+MLKEM makes about as much sense as an AES+Serpent cascade. It is simultaneously the case that MLKEM is far less mysterious than programmers on message boards think it is, and that conventional ECC and finite field cryptography is muc…

> The more cryptography-literate you are, the more likely it is you think hybrids are silly You are if you're considering a cypher that's extremely likely to be secure. In this case we're ok to introduce something with a chance to be quantum-resistant before it's been studied enough, because we want a chance of being quantum-resistant soon. But that's only ok if you add it to the existing, reliable, systems. Were the…

It's "cipher". But we're not talking about ciphers; we're talking about key establishment algorithms.

Re: NSA and IETF: Fairness

#67

Post by g-b-r »

tptacek wrote: post #66
g-b-r wrote: post #63

Earlier quoted context omitted.

> The more cryptography-literate you are, the more likely it is you think hybrids are silly You are if you're considering a cypher that's extremely likely to be secure. In this case we're ok to introduce something with a chance to be quantum-resistant before it's been studied enough, because we want a chance of being quantum-resistant soon. But that's only ok if you add it to the existing, reliable, systems. Were the…

It's "cipher". But we're not talking about ciphers; we're talking about key establishment algorithms.

Ok, yes, replace "cypher" with cryptographic primitive.

Maybe I said cypher for the AES+Serpent mention (and because I like cyberpunk xD)

Re: NSA and IETF: Fairness

#68

Post by g-b-r »

To those who say that approving or not this RFC won't make any difference:

«- Liaisons: We received liaison statements from multiple SDOs including O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing support for the publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF to provide a stable normative reference»

(https://mailarchive.ietf.org/arch/msg/tls/ol2otAvtdDrdz_xY0_...)

Re: NSA and IETF: Fairness

#69

Post by rurban »

JumpCrisscross wrote: post #6

> Secret NSA documents showed that NSA pushed DES in the 1970s to "drive out competitors" while knowing that DES was "weak enough" to break; meanwhile NSA publicly claimed that it would use DES Is this true? The NSA pushed for weaker cryptography it could break versus stronger cryptography our adversaries couldn't?

Sure. Everbody knows that

Re: NSA and IETF: Fairness

#70

Post by yasaheblasa »

tptacek wrote: post #8

The 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 Mathematicians in the US, that may have gone down with more cryptocurrency firms, etc, but those firms are not researching algorithm families that may or may not replace the standards with all that much interest.
Post reply on HN