Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There are a couple comments from that discussion that mirror my general take.

The standard should be defining something that is good for the general case, without a lot of levers. KISS! That means giving people 4 different PRNG algorithms, plus a hardware interface, etc, is not the right direction. Your average programmer shouldn't have to make a decision more complex than "secure" or "fast" and the API should clearly make the distinction.

In this case, the linux kernel finds about the right match with /dev/random and /dev/urandom. If you want something more complex then you can pick up a 3rd party library and spend 6 months learning about random numbers, how to test their randomness, seed a CSPRNG, etc. Otherwise leave the implementation choices to the experts and make it easy for the common programmer.



On Linux /dev/random and /dev/urandom are rather oddly misshapen abstractions. Neither device has sensible behaviour. /dev/random blocks unnecessarily after seeding, and /dev/urandom doesn't block even if it hasn't been seeded yet. Contrast that with FreeBSD, which provides exactly the behaviour I'd want: block until the RNG has been seeded, then never block again.


> /dev/random blocks unnecessarily after seeding

That's because it's supposed to be a random-number-generator, not a pseudo-random-number-generator. It needs real entropy.


I am not a cryptographer, but my impression is that the points at which /dev/random stops are not well-justified. It doesn't directly pass out entropy, but instead feeds it through a cryptographically-secure PRNG first, making it a rather arbitrary line that's drawn to decide when entropy is 'exhausted'.

There was a brief HN discussion on the topic when FreeBSD made their change: https://news.ycombinator.com/item?id=8550457


Right, but the point is that the entropy can be reused.

I mean, maybe you say that my next 4,096 bits of entropy need to be completely independent from the last 4,096, but ib the usual case, I doubt it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: