FWIW: I don't like OpenSSL as a CSPRNG; I think you'd generally better off replacing it with direct reads from urandom.
Another useful thing to know: there is lately a push towards crypto constructions that minimize dependencies on randomness. For example, there's "deterministic" DSA that replaces the nonce with a uncorrelated (psuedorandom) bits from digest functions. If you see people talking about cryptosystems being bad or good based on CSPRNG dependencies, that's the idea they're talking about.
This was a good post. For the record, we've been repeatedly trying and failing to hire Daniel Franke ever since that HN hack.
What's not to like about it?! The potential for multiple processes to share PRNG state after fork()s (unless the processes explicitly reseed)? The tri-state return value from the RAND_bytes() function (success, failure, more failure)?
Extrapolating a little when you say you don't like openssl as a CSPRNG, do you mean you don't like any of the CSPRNGs or just the openssl one? For e.g. NIST specified some CSPRNGs in the DSA specification.
You don't like them because the application might end believing it has more entropy than it really has or are there other reasons?
I don't like the OpenSSL CSPRNG in particular for the same reasons 'rwg cited. But more broadly, I don't like app-layer CPSRNGs. CSPRNGs are one thing that benefits from being centralized on the OS.
Another useful thing to know: there is lately a push towards crypto constructions that minimize dependencies on randomness. For example, there's "deterministic" DSA that replaces the nonce with a uncorrelated (psuedorandom) bits from digest functions. If you see people talking about cryptosystems being bad or good based on CSPRNG dependencies, that's the idea they're talking about.
This was a good post. For the record, we've been repeatedly trying and failing to hire Daniel Franke ever since that HN hack.