Daniel J. Bernstein

Weighting functions are useless. If you mix entropy properly, in the absence of an _active_ attacker, the output will be no worse than the best entropy source. In the presence of an attacker they're just as useless, if not pernicious.

Modern PRNG frameworks moved away from weighting years ago[1] because it not only has dubious benefit, but engineers suck at estimating entropy, so the estimates created a false sense of security. For example, the entropy estimates for hard drives were for a long time based on a single research publication, which as hard drives evolved over the years became increasingly irrelevant--assuming it wasn't irrelevant the day after it was published. Kernel engineers would try to add conservative margins, but if the original quantity has no basis in reality those efforts are just hand-waving.

This is pretty much how all entropy estimates go. The research that goes into the estimates can be extremely rigorous and sound. The problem is not only ensuring the estimates are relevant to your mix of hardware, but that they remain relevant over time. New designs and new manufacturing methods come online on an almost daily basis, even for what appear to be identical products. Combined with the dubious benefit at the outset, trying to maintain the integrity of the estimates is little more than a fool's errand.

With the exception of first-boot behavior, where you want to ensure there's "enough"[1] initial entropy, even accurate estimates don't provide any…

It’s possible that in the specific sense that NIST defined, KYBER-512 isn’t as strong as AES-128. However, that doesn’t mean that it’s less secure in general. E.g. DJB himself wrote a good article[1] on how even though 128-bit AES and 256-bit elliptic curve crypto are thought of as same “security level”, actually there are attacks against AES that just don’t apply to ECC when you consider multi-target security models (i.e., when you consider a population of users not just one). I wouldn’t be surprised if similar things applied to lattice-based crypto, but I don’t know enough about it. And even if we take the reduced security level given by DJB, it still seems big enough to be out of reach to any realistic attack.

But by all means feel free to go one bigger and pick KYBER-768, and I believe lots of people do recommend this. Obviously, there is a performance penalty (as there is when moving from AES 128 to 256), and for PQ schemes there is also more importantly also a big increase in the size of bytes on the wire when public keys have to be exchanged (e.g. in TLS) - in this case a jump from 800 bytes to 1,184 bytes (a 48% increase). (Compare this to ECC public keys which are typically around 32-65 bytes, depending on encoding).

[1]: https://blog.cr.yp.to/20151120-batchattacks.html

FWIW, https://blog.cr.yp.to/20240102-hybrid.html reads to me like a more direct attempt to engage with the counterarguments.

I am curious what the costs are seen to be here. djb seems to make a decent argument that the code complexity and resource usage costs are less of an issue here, because PQ algorithms are already much more expensive/hard to implement then elliptic curve crypto. (So instead of the question being "why don't we triple our costs to implement three algorithms based on pretty much the same ideas", it's "why don't we take a 10% efficiency hit to supplement the new shiny algorithm with an established well-understood one".)

On the other hand, it seems pretty bad if personal or career cost was a factor here. The US government is, for better or worse, a pretty major stakeholder in a lot of companies. Like realistically most of the people qualified to opine on this have a fed in their reporting chain and/or are working at a company that cares about getting federal contracts. For whatever reason the US government is strongly anti-hybrid, so the cost of going against the grain on this might not feel worth it to them.

It's disappointing to read this thread. Even tptacek, a prominent speaker on Hacker News, exhibits bizarre ignorance regarding this topic.

Generally speaking, it seems to me that much sloppy thinking in the current debate involves the mixture of the following basic errors:

1) Ignorance about biology. Evolutionary biology has been an exceptionally fertile section of science for the last decades, and provided deeper understandings on many biological phenomenon, including human behaviors. The accusers' understanding of biology (e.g. condemning it as "genetic determinism") is at least 50 years behind.

2) Poor understanding of the due process. Calling a random petition to condemn a person publicly is exactly a witch hunt. History proves that it's a very error-prone way to punish someone, and no civilized country accept it as a proper procedure anymore.

As to (2) I'd recommend everyone to read DJB's "The death of due process". It is very important, because it may be you (or your family) to be hung by lynch mobs next time.

https://blog.cr.yp.to/20160607-dueprocess.html

> this slightly time-saving but potentially dangerous choice?

The one and only danger is during the machine's boot process, because while /dev/random and /dev/urandom use the same data:

* on linux /dev/random has a silly and unfounded entropy estimator and will block at arbitrary points (used to be a fad at some point, but cryptographers have sworn off it e.g. Yarrow had an entropy estimator but Fortuna dropped it)

* also on linux, /dev/urandom never blocks at all, which includes a cold start, which can be problematic as that's the one point where the device might not be seeded and return extremely poor data

In fact the second point is the sole difference between getrandom(2) and /dev/urandom.

If you're in a steady state scenario (not at the machine boot where the cold start entropy problem exists) "just use urandom" is the recommendation of pretty much everyone: tptacek, djb, etc…

https://www.2uo.de/myths-about-urandom/

https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

http://blog.cr.yp.to/20140205-entropy.html (see bottom of page)

"NSA grade" irks me - to think these guys have your best interest at heart. In the 1970's they weakened DES [1]. In 2015 the NSA created a backdoor and pressured companies into installing it [2]. In 2016 you had the leaked tools stolen and used by the Shadow Brokers / Equation Group [3]. More recently the NSA made arguments against double encryption to combat weaknesses in potential quantum-safe encryption algorithms [4].

The point is that "NSA grade" likely means "NSA accessible". The major difference between WPA2 and WPA3 is the individual encryption. My guess would be that there is some backdoor during SAE and they could force a complete reconnect by temporarily jamming/disrupting all users on a network.

[1] https://arstechnica.com/information-technology/2013/09/the-nsas-work-to-make-crypto-worse-and-better/

[2] https://twitter.com/matthew_d_green/status/1433470109742518273

[3] https://en.wikipedia.org/wiki/The_Shadow_Brokers

[4] https://blog.cr.yp.to/20240102-hybrid.html