An Analysis of OpenSSL's Random Number Generator

Post by ryuuchin » Wed, Apr 13, 2016, 6:48 AM UTC

geofft wrote: post #15

miles wrote: post #13

Earlier quoted context omitted.

"/dev/urandom and CryptGenRandom which are known to be good" Check out "A good idea with bad usage: /dev/urandom" : http://insanecoding.blogspot.com/2014/05/a-good-idea-with-ba... Just stumbled onto it in the new submissions queue: https://news.ycombinator.com/item?id=11485876

... I'm not sure I can take an article seriously that suggests "but what if the attacker can modify files in /dev?". In any case, the meaningful concerns from that article have been addressed with the getrandom syscall on Linux, introduced a few months after this article was written: https://lwn.net/Articles/606141/ Perhaps we should start saying "getrandom" / "getentropy" instead of "/dev/urandom", but they're the s…

Post by rurban » Wed, Apr 13, 2016, 7:45 AM UTC

technion wrote: post #19

slavik81 wrote: post #11

Earlier quoted context omitted.

That link appears to confirm cyphar's assertion that /dev/urandom may produce a low-entropy output stream in certain circumstances. > Linux's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.

The part of this myth is down to what those circumstances are. What's generally accepted is that, early during first boot, urandom still produces 'random' data without enough entropy for it to be sufficiently random. What's a myth is that 'entropy can run out' and somehow a sufficiently seeded CSPRNG needs to block after a few reads while it gathers more entropy. The problem in these discussions is that one, edge cas…

Post by ICallsBS » Wed, Apr 13, 2016, 8:14 AM UTC

rootw0rm wrote: post #8

I actually have several TB of OpenSSL PRNG output (256 bit len) that I've been analyzing. A fairly modest sample size, but I've come across some interesting patterns at the bit level. It's kind of a pain in the ass to write efficient analytics for a binary 256 bit pattern as a matter of fact.

Post by Natanael_L » Wed, Apr 13, 2016, 9:27 AM UTC

rurban wrote: post #23

technion wrote: post #19

Earlier quoted context omitted.

The part of this myth is down to what those circumstances are. What's generally accepted is that, early during first boot, urandom still produces 'random' data without enough entropy for it to be sufficiently random. What's a myth is that 'entropy can run out' and somehow a sufficiently seeded CSPRNG needs to block after a few reads while it gathers more entropy. The problem in these discussions is that one, edge cas…

Which is was exactly described in this paper. It's not cargo cult, it's the exact technical explanation what happens when the entropy runs out, while it should be blocking or in the OpenSSL case just use a proper API to avoid the exact same confusion (this is low entropy as with /dev/urandom ) or add more mixing rounds. The cargo cult you are describing is exactly the cargo cult trap you are falling into.

Post by caf » Wed, Apr 13, 2016, 10:14 AM UTC

ryuuchin wrote: post #4

I can't understand Why OpenSSL continues to use it's own PRNG implimentation when we have /dev/urandom and CryptGenRandom which are known to be good. This is basically what BoringSSL does (although if you have rdrand then it will get filtered through a ChaCha20 instance). I'm pretty sure OpenSSL doesn't even reseed its PRNG on Windows unless the calling application does it so I'm not sure how that's safe either. If y…