Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info>: > On Wednesday 24 February 2016 18:20, Marko Rauhamaa wrote: >> Steven D'Aprano <st...@pearwood.info>: >>> And that is where you repeat something which is rank superstition. >> >> Can you find info to back that up. > > The links already provided go through the evidence. For example, they > explain that /dev/random and /dev/urandom both use the exact same > CSPRNG.
A non-issue. The question is, after the initial entropy is collected and used to seed the CSPRNG, is any further entropy needed for any cryptographic purposes? Are there any nagging fears that weaknesses could be found in the deterministic sequence? /dev/random is supposed to be hardened against such concerns by stirring the pot constantly (if rather slowly). Here's what Linus Torvalds said on the matter years back: > No, it says /dev/random is primarily useful for generating large > (>>160 bit) keys. Which is exactly what something like sshd would want to use for generating keys for the machine, right? That is _the_ primary reason to use /dev/random. Yet apparently our /dev/random has been too conservative to be actually useful, because (as you point out somewhere else) even sshd uses /dev/urandom for the host key generation by default. That is really sad. That is the _one_ application that is common and that should really have a reason to maybe care about /dev/random vs urandom. And that application uses urandom. To me that says that /dev/random has turned out to be less than useful in real life. Is there anything that actually uses /dev/random at all (except for clueless programs that really don't need to)? <URL: http://article.gmane.org/gmane.linux.kernel/47437> > If you don't trust the CSPRNG, then you shouldn't trust it whether it comes > from /dev/random or /dev/urandom. If you do trust it, then why would you > want it to block? Blocking doesn't make it more random. It might not make it more secure cryptographically, but the point is that it should make it more genuinely random. > That's not how it works. It just makes you vulnerable to a Denial Of > Service attack. Understood. You should not use /dev/random for any reactive purposes (like nonces or session encryption keys). > There's that myth about urandom being "less random" than random again, > but even this guy admits that the difference is "extremely hard" > (actually: impossible) to measure, and that CSPRNG's "work". Which is > precisely why OpenBSD uses arc4random for their /dev/random and > /dev/urandom, and presumably why he wants to bring it to Linux. That's for the cryptographic experts to judge. CSPRNG's aren't always as CS as one would think: In December 2013, a Reuters news article alleged that in 2004, before NIST standardized Dual_EC_DRBG, NSA paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library, which resulted in RSA Security becoming the most important distributor of the insecure algorithm. <URL: https://en.wikipedia.org/wiki/Dual_EC_DRBG> > The bottom line is, nobody can distinguish the output of urandom and > random (apart from the blocking behaviour). Nobody has demonstrated > any way to distinguish the output of either random or urandom from > "actual randomness". There are theoretical attacks on urandom that > random might be immune to, but if so, I haven't heard what they are. What I'm looking for is a cryptography mailing list (or equivalent) giving their stamp of approval. As can be seen above, NIST ain't it. It seems, though, that cryptography researchers are not ready to declare any scheme void of vulnerabilities. At best they can mention that there are no *known* vulnerabilities. > What evidence do they give that /dev/urandom is weak? If it is weak, > why are they using it as the default? It's a big mess, but not a mess I would disentangle. Once the crypto libraries, utilities, facilities and the OS come to a consensus, I can hope they've done their homework. As it stands, the STRONG vs VERY STRONG dichotomy seems to be alive all over the place. Marko -- https://mail.python.org/mailman/listinfo/python-list