from Hacker News

Myths about /dev/urandom

by petrosagg on 8/31/15, 8:52 PM with 106 comments

  • by po on 9/1/15, 12:55 AM

    Why hasn't someone qualified re-written that unix man page by now? I've been reading cryptographers trying to explain all of this for a while now. I feel like that would help put a lot of this to rest and save everyone time.

  • by tytso on 9/1/15, 4:25 AM

    Actually, the preferred and recommended way to get randomness on modern kernels is to use the new getrandom(2) system call, with the flags argument set to zero.

    http://man7.org/linux/man-pages/man2/getrandom.2.html

    With the flags set to zero, it works like the getentropy(2) system call in OpenBSD. In fact, code that uses getentropy(buf, buflen) can be trivially ported to Linux as getrandom(buf, buflen, 0).

  • by antirez on 9/1/15, 10:36 AM

    The root problem is that cryptography is not usable without some understanding. In the latest days we developed an addiction for "best practices" like "use bcrypt", "use /dev/random" or alike which in the field of cryptography are not enough: understanding is the only possible path. Actually, this is true for most things, it just shows up more obviously in the field of cryptography because of the security concerns. So we should replace "use bcrypt" with "Read Applied Cryptography & other books".

  • by AndyKelley on 9/1/15, 1:22 AM

    Thanks for this. Time to go fix my code[1].

    [1]: https://github.com/andrewrk/genesis/blob/0d545d692110d33068d...

  • by msm23 on 9/1/15, 3:15 AM

    I prefer to trust the NSA on these matters. They end up saying much of what the author has written, but they make it clear why you want to use one vs the other.

    The excerpt below is from https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/S... (which in turn also references https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/S... )

    Unix-like Platforms (e.g. Linux, Android, and Mac OS X):

    Application developers should use the fread function to read random bytes from /dev/random for cryptographic RNG services. Because /dev/random is a blocking device, /dev/random may cause unacceptable delays, in which case application developers may prefer to implement a DRBG using /dev/random as a conditioned seed.

    Application developers should use the “Random Number Generators: Introduction for Operating System Developers” guidance in developing this solution. If /dev/random still produces unacceptable delays, developers should use /dev/urandom which is a non-blocking device, but only with a number of additional assurances:

    - The entropy pool used by /dev/urandom must be saved between reboots. - The Linux operating system must have estimated that the entropy pool contained the appropriate security strength entropy at some point before calling /dev/urandom. The current pool estimate can be read from /proc/sys/kernel/random/entropy_avail.

    At most 2^80 bytes may be read from /dev/urandom before the developer must ensure that new entropy was added to the pool.

  • by panic on 9/1/15, 1:58 AM

    Why doesn't Linux follow FreeBSD and provide a single interface (under two names, maybe, for compatibility)? Is there any reason to use /dev/random?

  • by aidenn0 on 9/1/15, 12:14 AM

    Is there a patch to make /dev/random behave like /dev/urandom? I've had at least some server software stall blocking on /dev/random, and I already build my own kernels, so incorporating such a patch is easy.

  • by 1_player on 9/1/15, 1:56 PM

    Is there anyone that, with full access to the machine/kernel, has managed to predict the output of random/urandom?

    I know that a PRNG is predictable if you know all the input variables, and the code for it is publicly available, but has anybody in practice been able to exploit that?

    EDIT: that's an honest question. I'd like to read a paper about that.

  • by theophrastus on 9/1/15, 1:27 AM

    Interesting and edifying, thank you. I wonder how the recent 4.2 kernel release affects this: Linux 4.2 Released Improving Cryptography Options[1]

    [1]: http://www.linuxplanet.com/news/linux-4.2-released-improving...

  • by snorrah on 9/1/15, 1:47 AM

    Very interesting article. Clears up the preconceptions I had about using /dev/random over /dev/urandom ("it's more secure!") and explains why in very straightforward language.

  • by vbezhenar on 9/1/15, 8:48 PM

    Java is known to read /dev/random when dealing with SecureRandom class. In particular it might cause extremely slow starting time for Tomcat on fresh virtual machine. There's parameter "-Djava.security.egd=file:/dev/./urandom" and I always felt unsafe using it. Thanks to this article, now I won't regret it even theoretically.

    Fun thing is, if you pass "/dev/urandom" to this parameter, Java will read /dev/random anyway. May be that was a wise decision 20 years ago.

  • by wangweij on 9/1/15, 2:28 AM

    This is my understanding: /dev/urandom is just a blind producer returning any number in some pool; /dev/random is a producer as well as an inspector, it returns the same number from the pool but it also has an extra eye on the source of that pool and refuse to work if it believes the source is of low quality -- here, not enough entropy.

  • by frankzinger on 9/1/15, 5:30 AM