Live data from Hacker News

NSA and IETF: Fairness

blog.cr.yp.to

121–130 of 198 posts

Re: NSA and IETF: Fairness

#121
post #93
post #89

Earlier quoted context omitted.

The standardization process should weed out 'footguns' that are prone to accidentally (or maliciously) lowering the security bar.

To point out some positive examples of what RFCs should include: RFC 5288 s3 (AES-GCM): "Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security."[1] RFC 7748 s5 (X25519): "The cswap function SHOULD be implemented in constant time (i.e., independent of the swap argument)…

You are confused about what this RFC is. It's not the enabling RFC for PQC in TLS, or for MLKEM. It's documentation about a specific set of parameters for doing pure, as opposed to hybrid, MLKEM. It defers the guidance you're looking for to other RFCs.

Re: NSA and IETF: Fairness

#122
post #111
post #81

Earlier quoted context omitted.

Yes, and strongly argued against lattice schemes generally . DJB submitted a lattice scheme under the theory that if the advocates of lattice schemes were able to win the argument about the performance properties then there should be a choice of an extremely conservatively designed one. DJB himself has consistently advocated for Classic McEliece in any application which can accept its performance characteristics (whi…

NTRU based schemes are not the most conservative. NTRU is an old design from the 90s, that had some shocking structural attacks against it appear ~2016. These attacks so far are only relevant for moduli q ~ (1/100) n^{2.3...}. This makes them worse than conventional attacks against NTRU-based PKE. But they completely killed roughly half of all NTRU-based fully homomorphic encryption schemes, and are a (major) structu…

The general C.W. I've heard is that if something happened that made MLKEM look theoretically shaky (pretty unlikely, but whatever), you fall back to something like FrodoKEM, which is plain LWE with no affordance for NTT or anything like it; no structure, no performance.

Re: NSA and IETF: Fairness

#123
post #80
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…

I might have expected you'd be once bitten twice shy after having once taking an aggressive position that DUAL-EC would never have backdoored anyone in practice... 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). Th…

None of this makes any sense once you understand that NSA had no hand in designing MLKEM, or in shaping the LWE research that led to it. NSA designed Dual-EC. MLKEM won an open competition; its entrants are among the most reputable cryptographers in the world.

Re: NSA and IETF: Fairness

#124

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

> “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. The GOST cipher, which is Russia's AES equivalent, is also in an RFC: * https://datatracker.ietf.org/doc/html/rfc9189 * https://en.wikipedia.org/wiki/GOST_…

In fairness, I do think that this situation is somewhat different. As I noted above (https://news.ycombinator.com/item?id=48812792), there are two main routes to an Informational RFC of this kind.

* Through the IETF

* Through the Independent Stream

The GOST documents went through the Independent Stream and therefore do not have IETF imprimateur. These documents are proposed for the IETF Stream and therefore require IETF Consensus to publish.

I know this is all super confusing. The basic problem is that the vast majority of RFCs come out of the IETF and so people often act as if all RFCs do. This is of course in part why people pursue Independent Stream publication rather than just publishing things on their own..

Re: NSA and IETF: Fairness

#125

Earlier quoted context omitted.

Heh heh heh. 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 DAR…

In the 90s, you as a private person were not supposed to have access to encyption which could not be broken by NSA. "The longest key size allowed for export without individual license proceedings was 40 bits, so Netscape developed two versions of its web browser. The "U.S. edition" had the full 128-bit strength. The "International Edition" had its effective key length reduced to 40 bits by revealing 88 bits of the ke…

No. In the 1990s, you weren't allowed to export cryptography the NSA couldn't break. Strong cryptography was widely available in the 1990s.

(I had the pleasure of shipping a commercial product, back in the days when those things shipped in shrink-wrapped boxes, that carried strong cryptography, and had to deal with the export regime. It was not fun.)

Re: NSA and IETF: Fairness

#126
post #110
post #89

Earlier quoted context omitted.

The standardization process should weed out 'footguns' that are prone to accidentally (or maliciously) lowering the security bar.

using pure ML-KEM is not a footgun. Some people may have doubts about lattice-based cryptography, despite being securely deployed in Chrome nearly a decade ago. Some people have doubts about many things. The fact that people have doubts does not make the scheme a "footgun".

It is if literally the only thing you've ever read about the technical details of LWE cryptography is Daniel Bernstein.

Re: NSA and IETF: Fairness

#128

Earlier quoted context omitted.

[flagged]

What does this even mean? By the exact same logic you could impeach literally any algorithm.

It means that your argument is “the NSA couldn’t have subverted ML-KEM, it was written by Europeans”.

You assiduously pretend that this scenario isn’t possible: * The NSA reviewed the PQ submissions and realized that there’s one they already know how to break at scale: ML-KEM, because their army of math PhDs spent a couple decades understanding it better than the rest of the world * The NSA decides they want ML-KEM deployed everywhere so that the world is full of transparent-to-NOBUS cryptography * The NSA spends the entire PQ contest placing their thumbs on the scale of the process, violating their 2014 post-Snowden promises of increased transparency, to make their NOBUS dreams happen

The actions of NSA and NIST personnel make the most sense with the assumption that they desperately want to standardize ML-KEM and ML-KEM alone because _they already know how to break it_. What doesn’t make any sense is why the private sector is cheerfully going along with it —- even Charlie stopped letting Lucy hold the football at some point.

Re: NSA and IETF: Fairness

#129

Earlier quoted context omitted.

What does this even mean? By the exact same logic you could impeach literally any algorithm.

It means that your argument is “the NSA couldn’t have subverted ML-KEM, it was written by Europeans”. You assiduously pretend that this scenario isn’t possible: * The NSA reviewed the PQ submissions and realized that there’s one they already know how to break at scale: ML-KEM, because their army of math PhDs spent a couple decades understanding it better than the rest of the world * The NSA decides they want ML-KEM d…

You're just restating the same claim with more words. It obviously proves too much. You can stick any algorithm, from MLKEM to SNTRUP to CRC32, in the same comments and get the same result.

Re: NSA and IETF: Fairness

#130
post #116

Earlier quoted context omitted.

you would make poor decisions then. McEliece recently (in the last month) had a large new attack against it https://eprint.iacr.org/2026/1232 This doesn't hit classic McEliece yet, but is part of a line of work that Randriambololona has been doing, which are at a minimum very concerning for the security of McEliece.

certainly a concern, and a good reason to use multiple cryptosystems together. unfortunately there are probably similar papers for Kyber which are NSA property and will never see the light of day. they do employ a lot of mathematicians. for applications where key exchange need not be particularly fast or compact, I would even throw in 4096 MP-RSA in (tuned to whatever size the exchange can tolerate) as a hedge agains…

there is no indication there are similar papers. Curiously, the best lattice cryptanalysts in the world are chinese and european (here I'm thinking of people like Ducas, Albrecht, and Ding). It's actually a weird blindspot of american cryptography (this isn't true for all cryptanalysis, but in general European cryptography is "more concrete" vs "theoretical" american cryptography).

This isn't to say that it is impossible for the NSA to have their own private cryptanalysis. It is to say they're not some magical fairy that produces non-trivial attacks. They, like any other organization, need to develop talent. In the past they have been able to do this (they, through the CCR, hired Don Coppersmith in 2005. A VERY notable cryptanalyst at the time). I am unaware of any lattice cryptanalysts who have "gone dark" in a way similar to how Coppersmith did in ~2005.

Note that we also have theoretical reasons to be more confident in the hardness of ML-KEM. The reasons are technical (and worse than the practical reasons we have, namely people have iterated on attacks and the attacks stopped getting appreciably better). But it is (curiously) the hardness assumption we perhaps have the best (theoretical) justification for why it is hard.

Using RSA as a hedge would be incredibly stupid. Index calculus attacks were significantly improved in the 2010s, at least for small characteristic finite field DH. These improvements have only tangentially hit RSA. I've heard a integer factorization record holder directly say there's no real barrier to similar improvements hitting factoring. It hasn't been done, so it isn't "easy". But also people wouldn't be surprised if it was done. The record for binary characteristic finite field DH is ~30k bits (by an academic team. governments could throw more money at it of course).

Post reply on HN