You would expect a decent rebuttal if wrong, and an acknowledgement if correct.
I'm not aware of either. I'd love to know if NIST has formally accepted their arithmetic flaw. It's possible they did, and believe they are north of need supporting Kyber-512 irrespective.
This stood out to me:
> For comparison, Bitcoin mining did only about 2^111 bit operations in 2022. ("Only"!)
Anyone have a source for this? Google results suggest in 2022 Bitcoin miners reached ~209 quintillion hashes (209 exahashes) per second. I don't know how many bit operations SHA-1 takes, but dividing 2^111 by 209 * 10^18 * 86400 * 365 gives 393891, which doesn't sound unreasonable for number of bit operations per SHA-1 hash.
Basically, it's fascinating that global compute is reaching those kinds of numbers. Even more fascinating is that it's just Bitcoin mining, so global total computations must be some multiple of that (3x? 10x? 100x?). These are numbers once considered (still considered?) unfathomable, let alone a quantity applicable to human endeavor. And that's 2022. Today the Bitcoin hash rate is 4.5x greater.
That's pretty messed up, guess that's another sombering fact to the pile. I'd have expected that serious security stuff always involves mechanized math proofs every step of the way, making such silly mischaracterizations impossible. Not a fun thing to learn that this is not what happens.
Previously:
https://news.ycombinator.com/item?id=37756656 - Debunking NIST's calculation of the Kyber-512 security level (2023-10-03, 201 comments)
I can see they say many problems with what NIST is doing. One question is: Does someone bribe (or otherwise coerce) them? If so, is that why they are being deceptive, and why they would not respond to (or explain) some things?
If a system has parameters, another issue is whether or not a different implementation is required due to the parameters being different. There are some reasons why a separate implementation might be desirable anyways in some cases, but sometimes it would be possible to change the parameters at run time.
Another consideration is patents; they should not recommend patented or secret algorithms. Cryptanalysis will be difficult if the specification is not freely available to anyone who wants to read it, and implementation can be a problem if patent licensing is required. Wikipedia says that NTRU is patented but "Security Innovation exempted open-source projects from having to get a patent license"; that might be good enough.
Wikipedia also says that Kyber is a key encapsulation mechanism but NTRU is a public key cryptosystem, so they would not be the same kind of things, anyways. However, you could also use a public key cryptosystem like a key encapsulation mechanism if you have another method of making up a key securely at random. But, Wikipedia says "it is easier to design and analyze a secure KEM than to design a secure public-key encryption scheme as a basis" (I do not know the details of the quoted part to judge this, but the unquoted part seems obvious to me).
Another alternative might be using multiple algorithms with independent keys (to be secure, the keys will have to be independent; however, you might have to be careful that they really will be independent), e.g. by using Kyber first and then encrypting the result with NTRU. But, that depends on what your requirements are.
As another comments (https://news.ycombinator.com/item?id=37756656) had mention, they may have different requirements than yours, such as hardware, so that is another issue.
None of that is an excuse for what NIST seems to be doing though (according to the article); they are additional concerns than those ones.