Modulo the fact that Debian shouldn't be mucking with the inner workings of packages in the first place, sure; stubbing out OpenSSL's CSPRNG with calls to the OS CSPRNG seems like a reasonable plan. It is, by the way, part of the NaCL design too.

Last I heard, there were still some "security oriented" OSes using RC4 for their /dev/random.

arc4random predates modern OS CSPRNGs.

So does OpenSSL. I think it's just not reasonable to expect a widely-portable crypto primitive and protocol library to judge the quality of the host /dev/[u]random and delegate to it. Of course, they seed from the host device and try to estimate the entropy it provides.

Even that OS with the biased /dev/[u]random using RC4 because it was fast would keep a separate RC4 state in each process' libc to avoid the overhead of kernel calls.

So then, you think NaCL's design decision to rely on /dev/urandom was a mistake?

I think if NaCL ever gets popular that design decision will bite somebody, somewhere, on some OS.

Our crypto libraries need to provide their own belt to wear with the OS-provided suspenders. Yes, I know about potential fork() bugs, but our modern VM-crazed deployments introduce that possibility at kernel level too. We need our good crypto implementers shipping good lightweight CSPRNGs, rather than the kernel developers who try to compensate with 6000 bit entropy pools.

If some OS screws up urandom so much that it bites someone, it'll bite a huge number of different apps, and not just the ones that use NaCL. Like it or not, urandom has to work; all sorts of things depend on it. The urandom ship has sailed.

Meanwhile, better to have just one codebase to review, rather than 100 crappy ones, like the SecureRandom from Harmony.

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'll wager your team has reviewed more crypto code, and more recently, than DJB.

Meh, this conversation needed to be over

      do random_beverage(); while (self->is_conscious());

Tell you what: I will ask DJB tonight and see what he says.