Key Material

I recommend reading https://keymaterial.net/2025/11/27/ml-kem-mythbusting/, which explains (1) why it's not possible for ML-KEM (the thing most people are using for post-quantum encryption) to be backdoored the way Dual_EC_DRBG was, and (2) some of the reasons some people don't like hybrids, not all of which are good but none of which should serve to undermine confidence in ML-KEM's security.

I recommend reading this perspective https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ceVcfmA75Hs/ Also, https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ ML-KEM is not "very new" compared to the age of other algorithms historically deployed.

Remember that the entities most likely to heed those governments recommendations are those providing services to said government and its military. I feel like the NSA pushing a (definitely misguided and obviously later exploited by adversaries) NOBUS backdoor has poorly percolated into the collective consciousness, missing the NOBUS part entirely. See https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ for whether the current standards can hide NOBUS backdoors. It talks about ML-KEM, but all recent standards I read look like this.

So, in this case it wasn't correct to do so, but there is actually a current algorithm which uses floating point: Falcon (aka FN-DSA). https://keymaterial.net/2026/05/13/so-you-want-to-deploy-fn-dsa/ talks about FN-DSA and has a section about how it's require to hand-implement floats to get constant-time operations.

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

This has been discussed before, and I believe the general consensus is that djb's objections don't make sense. The Key Material blog addresses this in a very good larger ML-KEM mythbusting post: https://keymaterial.net/2025/11/27/ml-kem-mythbusting/#:~:text=hybrids

For a counterpoint Sophie Schmieg recently wrote https://keymaterial.net/2026/06/18/on-hybrid-signatures/ arguing against hybrids. Putting EC and PQ algorithms together isn't trivial, and the complexity of using multiple algorithms in parallel can, itself, lead to more issues. In response to the implementation errors in ML-KEM, companies have moved to formal verification. Apple, for example, recently released[1] a formally verified ML-KEM implementation, where they formally verified the assembly of the implementation to verify that it matches the specification and that it's side-channel free. AWS, similarly, is using a formally verified ML-KEM implementation: "All AArch64 and x86_64 assembly is proved to be functionally correct, memory-safe, and of secret-independent timing (constant-time)" [2]. There are similar efforts (by both Apple, Amazon, and others) to formally prove ML-DSA implementations as well. [1]: https://security.apple.com/blog/formal-verification-corecrypto/ [2]: https://github.com/pq-code-package/mlkem-native