OK, so NaCL will not be guilty and they will be in good company.
I'm sure these principles of minimal redundancy will be of great comfort to those users who get their private keys exposed.
Do you see the paradox here? Find me these developers who are undoubtedly competent to implement their own CSPRNG, but prefer not to. These are the folks I want implementing the CSPRNG that will be generating my keys, rather than kernel developers who find entropy pools exciting.
You see my point, right? A lot of your security already depends on urandom working. Everyone knows this, and a lot of effort has gone into validating the kernel random driver (there have been some pretty good systems security papers on it). Given that you already depend on urandom, all a new CSPRNG gets most developers is a second single point of failure.
I get your point and I agree it's at least not a wrong way to look at it. But you say "the kernel random driver" as if there were only one for a crypto app developer to worry about.
We have already seen a huge number of bad keys generated. Is it that obvious at this point that kernel (and embedded system) developers are so much better at this than OpenSSL?
Is it possible that you just tend to look at more broken library and app crypto code during the course of your work? If you worked primarily with broken kernel crypto code, would you perhaps prefer (for your own use) a CSPRNG in a library written by your favorite experts?
It is true that we see a lot of broken randomness code, and it is also true that we pay a lot of attention to failures of different CSPRNGs, but my point of view on this is also influenced by things like the design paper Daniel Bernstein wrote for Nacl.
I'm sure these principles of minimal redundancy will be of great comfort to those users who get their private keys exposed.
Do you see the paradox here? Find me these developers who are undoubtedly competent to implement their own CSPRNG, but prefer not to. These are the folks I want implementing the CSPRNG that will be generating my keys, rather than kernel developers who find entropy pools exciting.