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

81–90 of 198 posts

Re: NSA and IETF: Fairness

#81

Post by nullc »

tptacek wrote: post #77
protocolture wrote: post #73

Earlier quoted context omitted.

He didnt say it did, he said "The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber"

He himself (co-)submitted a lattice KEM to the NIST competition.

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 (which are excellent except for the ginormous public keys), and spent many bytes trying to convince people that the set of applications that can is wider than they suspect.

Re: NSA and IETF: Fairness

#82

Post by rasengan »

avidiax wrote: post #5

This post was pretty technical. Let's explain a couple of terms: ML-KEM -- Module-Lattice-Based Key-Encapsulation Mechanism ML-DSA -- Module-Lattice-Based Digital Signature Algorithm solo PQ -- Using post-quantum crypto on its own ECC+PQ -- Using post-quantum crypto as a layer on top of traditional elliptical curve cryptography (ECC) So what's at stake here, is that the PQ crypto is not proven yet, and had recent imp…

> In the NSA's defense, combining cryptosystems also creates attack surfaces, timing problems, additional complexity, etc

Actually, Dr. Nadim Kobeissi formally proved that hybrid is secure, even if ML-KEM fails. [1]

[1] https://eprint.iacr.org/2026/1147

Re: NSA and IETF: Fairness

#83

Post by xnorswap »

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.

It's cypher in British English.

Re: NSA and IETF: Fairness

#84

Post by dhx »

tptacek wrote: post #43
g-b-r wrote: post #40

Earlier quoted context omitted.

"two timing leaks, KyberSlash1 and KyberSlash2, in every official reference Kyber implementation from 2017 through late 2023" Cryptographers can be good, bad, be more or less knowledgeable about applied cryptography, and possibly have agendas.

Huh, seen through that light, it's much clearer why we should all have ECC in our cryptosystems, because nothing has ever gone wrong with an ECC implementation.

This reads to me as an argument of "If you thought ECDSA was bad, wait until you see MLKEM?"

ECDSA history is repeating itself again when you consider how poorly the proposed MLKEM RFC deals with side channel resistance:

From draft-ietf-tls-mlkem-8:[1]

"Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."

From NIST SP 800-227:[2]

"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."

MLKEM is more complex and has more chances of stuff-ups in implementation than ECDSA did. A single sentence of encouragement is all that is on offer from this MLKEM RFC. It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]

As a point of reference for how hard it is to implement side channel resistant MLKEM see [4] (formal verification) and [5] (errors in formal verification). The MLKEM RFC doesn't offer a "Security Considerations" section to explain how difficult it is to implement side channel resistant MLKEM (perhaps it's easy :S), and if it were hard to implement, to recommend use of EdDSA+MLKEM for cryptography implemented on devices an attacker may be able to physically access, or when used on public networks as a workaround given that side channel resistant EdDSA would be easier to implement.

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1

[4] https://github.com/pq-code-package/mlkem-native/tree/main/pr...

[5] https://eprint.iacr.org/2026/192

edit: added reference 5

Re: NSA and IETF: Fairness

#85

Post by slim » 

  MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe
As you know, teams are vulnerable to infiltration and individuals to compromise. Corruption often stems from various motives, including ideology

Re: NSA and IETF: Fairness

#86

Post by thomasdeleeuw »

France and Germany propose hybrid schemes as well: The german position:

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat...

"The quantum-safe mechanisms recommended in this Technical Guideline are generally not yet trusted to the same extent as the established classical mechanisms, since they have not been as well studied with regard to side-channel resistance and implementation security. To ensure the long-term security of a key agreement, this Technical Guideline therefore recommends the use of a hybrid key agreement mechanism that combines a quantum-safe and a classical mechanism."

The french position, also quoting the German position:

https://cyber.gouv.fr/sites/default/files/document/follow_up...

"As outlined in the previous position paper [1], ANSSI still strongly emphasizes the necessity of hybrid wherever post-quantum mitigation is needed both in the short and medium term. Indeed, even if the post-quantum algorithms have gained a lot of attention, they are still not mature enough to solely ensure the security"

Re: NSA and IETF: Fairness

#87

Post by grayhatter »

tptacek wrote: post #42
teravor wrote: post #35

Earlier quoted context omitted.

the McEliece cryptosystem goes back to the 70s, doesn't mean it's as well studied as RSA. obviously people study popular cryptographic primitives more. having said that, I would trust McEliece more than Kyber.

You would trust McEliece more than Kyber because...

Because NIST chose it, after non-public input from the NSA. But if I am honest, NIST recommending it at all is enough to suspect it of being compromised. I say that as an American, and my non-american friends equally don't trust NIST on crypto topics.

The real problem I have is best described as I haven't read a single coherent argument responding to and rejecting the real concerns raised by the individual who after nist betrayed the internet with by recommending a compromised standard at the encouragement of the NSA. Is the person who wrote the crypto library everyone uses.

DJB puts his money (time) where his mouth is. I would critique his attachment to his own ego. But I'm in the group of people who haven't contributed enough yet to foss to get to throw stones. So I'll defer to people who can match his contributions. Until that happens, DJB's reputation is cares passionately about crypto and it's community, vs an US government group with a reputation for trying to sabotage crypto systems after passing secrets with the NSA, who refuses to provide details about their most recent secret messages.

I do find some of the arguments and refutations from the mailing lists compelling. But not all the them, and nothing directly from NIST. Equally some of DJB's appear to weaken his points. But like I said, I plan to trust the reputation each party has earned.

NIST has a history of behaving inappropriately, and unethically around it's cryptography recommendations. But the people currently in charge would rather pretend they're above it and not literally directly responsible for the organization with a well earned reputation. If you're given a 2nd chance after your partner catches you cheating, it's a reasonable requirement that you account for every second of your time, until you restore the reputation you destroyed.

Re: NSA and IETF: Fairness

#88

Post by some_furry »

g-b-r wrote: post #46
tptacek wrote: post #41

Earlier quoted context omitted.

It already exists. In fact, there are environments where it has to exist. So the argument he's making is that the IETF should pretend it doesn't exist.

Can you (or someone else) please give some example of those environments?

Telecoms.

I wrote at length about this debate in my blog post about threat modeling: https://soatok.blog/2026/06/30/soatoks-informal-guide-to-thr...

Re: NSA and IETF: Fairness

#89

Post by AdamN »

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.

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

Re: NSA and IETF: Fairness

#90

Post by some_furry »

grayhatter wrote: post #87
tptacek wrote: post #42

Earlier quoted context omitted.

You would trust McEliece more than Kyber because...

Because NIST chose it, after non-public input from the NSA. But if I am honest, NIST recommending it at all is enough to suspect it of being compromised. I say that as an American, and my non-american friends equally don't trust NIST on crypto topics. The real problem I have is best described as I haven't read a single coherent argument responding to and rejecting the real concerns raised by the individual who after…

> But if I am honest, NIST recommending it at all is enough to suspect it of being compromised.

NIST isn't the NSA and doesn't have the NSA's goals in mind. They are briefed by NSA on some matters, sure, but they're not the same organization.

NSA has a dual mission: Both SIGINT and COMINT. While the SIGINT folks might rub their hands and laugh evilly at the prospect of backdooring the PQ KEM that the Internet wants to move towards, this plot makes no sense at several levels.

The NSA has, through CNSA 2.0, committed to moving the entire federal government onto ML-KEM for top secret communications. The COMINT guys would shit themselves in rage if it turned out to be backdoored, even if there was enough hubris that the backdoor was NOBUS.

If you can't trust the people, you should always seek to understand their incentives if you want to predict their behavior.

My interpretation of the CNSA 2.0 move was that the NSA believes 1) that ML-KEM is actually the good stuff, and 2) the Suite B transition failed so spectacularly that they want to signal confidence in ML-KEM by recommending it without hybridization. Since pretty much everything they do is top secret, they probably can't comment further.

Post reply on HN