He didn't publicly call me an NSA shill, so I got off pretty easy. Obviously, I stand by what I said. I think it would be an understatement to suggest support for what Bernstein is arguing is a minority cause among cryptographers.

frankly every time this topic comes up he's quick to try to spread disinformation on djb's posts, so it's about time he got mentioned

[dead]

No. This whole situation is extremely dumb.

Bernstein is a co-author on NIST PQC competition submissions that didn't win (Classic McEliece, which just had a huge new research result, and Streamlined NTRU Prime, a lattice cousin to MLKEM).

When CRYSTALS/Kyber was selected in the NIST competition instead of SNTRUP, Bernstein didn't take it well. He claimed malfeasance by NIST and sued them for allegedly hiding documents.

Meanwhile, over the subsequent years, the world has continued turning on its axes. CRYSTALS/Kyber is now ML-KEM. Because many cryptography engineers and other security people think there's a lot of urgency to getting PQC deployed (because of harvest-now decrypt-later [HNDL] attacks), the IETF got a move on standardizing hybrid ECDH/MLKEM TLS 1.3, which is what everyone uses.

Nobody at IETF has ever to my knowledge even hinted that anyone should avoid hybrids. There is a standards-track RFC defining ECDH/ML-KEM hybrids.

There are environments where hybrids are problematic. You won't likely use any of them ever. Some of them occur within the US Government, and some of them are on highly constrained platforms (people seem to disbelieve this is ever really a thing but I once gameovered a smart meter because its RF protocol only had like 16 bits of counter space for CTR).

Because of this, there is also a proposed informational RFC --- not a standards track document --- that documents what pure MLKEM looks like in a TLS 1.3 setting. Bernstein's entire argument is that this is an NSA plot.

RFCs are used by developers as strict guidelines for implementation.

The mere publishing of an RFC has customarily been treated by developers as a stamp of approval from the IETF.

The NSA, contractors and their fans argue that simply adding a "RECOMMENDED=N" in an obscure section of this draft will somehow prevent said implementations in deployments.

However, as an example, Canada's NSA equivalent specifically requested the draft to be published so that they can use it to support their poor choice in deployment of solo ML-KEM nation-wide.

While ML-KEM may be sound, significant bugs in implementations in the wild continue to be published.

To be clear, CRQCs do not exist today.

ECC is battle tested, proven, and is used today.

It makes no sense to delete working cryptography and replace it with potentially buggy, non-battle tested implementations of new cryptography for a threat that does not yet exist today.

Instead, you fight HNDL [1] with hybrid which preserves the safety of today, and hopefully also, tomorrow.

No serious security person should be recommending otherwise which is, perhaps, why some may question the motives of those that are pushing for solo ML-KEM.

[1] Harvest now decrypt later

The purpose of a system is what it does.

https://archive.nytimes.com/www.nytimes.com/interactive/2013...

Imo "the optimal choice" is to be extremely skeptical to what comes to NSA proposing anything related to encryption/cryptography. From the first part of this blog series by DJB[1]:

> Try to put yourself in the mindset of NSA as an attacker. You have a massive budget to "covertly influence and/or overtly leverage" systems to "make the systems in question exploitable"; "to the consumer and other adversaries, however, the systems' security remains intact". One of your action items is to "influence policies, standards and specification for commercial public key technologies". Another is to "shape the worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS".

And when you read the Snowden docs and you come across to things like this 2010 GCHQ presentation[2], stating "for the past decade, NSA has lead an aggressive, multipronged effort to break widely used Internet encryption technologies" such as "SSL" and "SSH" and "VPNs"; that "cryptanalytic capabilities are now coming on line"; and that "vast amounts of encrypted Internet data which have up till now been discarded are now exploitable."

So we have these agencies like NSA and GCHQ, with stated, funded programs to make deployed cryptography exploitable (and historical evidence of them successfully doing just that)... It's an unbelievable conflict of interest for them to hold any role where they can shape what gets deployed. Absolutely bonkers.

And on DES specifically, it was both at once, not a binary. NSA in secret pushed IBM to cut the key size, while strengthening the algo against every attack except brute force. The design criteria were classified and IBM's own research docs were literally locked up under gov classification at NSA's request meanwhile when IBM personnel publicly denied any NSA involvement (and the NSA director publicly denied any algo weakening, again, a lie). So DES came out genuinely hardened against differential cryptanalysis but at the same time breakable by brute force by organizations with budgets like NSA's, by NSA's request/order.

For the "blue team" thing.. I guess it's actually better for them tactically to not spin off, because being NSA gives you authority in those circles. Standards bodies don't seem to treat the conflict of interest as a problem (as we can see), but rather as a qualification ("people who know cryptography best").

1: https://blog.cr.yp.to/20251004-weakened.html 2: https://web.archive.org/web/20240420184725if_/https://cdn.pr...

> which notably is not seeking recommendation status!

I don’t have a dog in this fight, but some extremely important RFCs are only on the “informational” track. RFCs 1945 (HTTP 1.0), 4627 (JSON), 2818 (HTTPS), etc.

because the NSA has never surreptitiously pushed bad standards they used to exploit before

/s