7

In Linux, just how random is /dev/urandom/? Is it considered safe?

Also is it possible to get a stream of 1's?

Recursion
  • 2,915
  • 8
  • 38
  • 51

3 Answers3

9

Note 4.5 years later: this is bad advice. See one of these links for details.

If you're generating cryptographic keys on Linux, you want /dev/random, even if it blocks-- you don't need that many bits.

For just about anything else, like generating random test data or unpredictable session IDs, /dev/urandom is fine. There are enough sources of entropy in most systems (timing of keyboard and mouse events, network packets, etc) that the output will be unpredictable.

Eric Seppanen
  • 5,923
  • 30
  • 24
  • 1
    +1, though its often easier and faster to gather your own entropy rather than waiting on a blocking /dev/random. I fill large files in this manner for 'bottled' entropy when working on monte carlo simulations, its much faster to bang the keys and move the mouse than it is to wait on /dev/random – Tim Post Dec 09 '09 at 00:29
  • I'm confused: how is this better than using /dev/urandom? – Eric Seppanen Dec 09 '09 at 00:41
  • 2
    Last time I looked /dev/urandom on linux returned the same output as /dev/random *as long as there is entropy in the pool* because they both use the pool. The difference is that urandom will fall back on a plain rehashing algorithm when there is no stored entropy, while random will wait until new entropy has been added. – dmckee --- ex-moderator kitten Dec 09 '09 at 01:53
  • 1
    See also [this article](http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/), which advocates using `/dev/urandom` exclusively. – Keith Thompson Feb 26 '14 at 02:53
  • 1
    True, I no longer believe my own answer. I like [this article](http://www.2uo.de/myths-about-urandom/) as well. – Eric Seppanen Jun 26 '14 at 22:24
4

Please check the man page:

Yarrow is a fairly resilient algorithm, and is believed to be resistant
     to non-root.  The quality of its output is however dependent on regular
     addition of appropriate entropy. If the SecurityServer system daemon
     fails for any reason, output quality will suffer over time without any
     explicit indication from the random device itself.

     Paranoid programmers can counteract this risk somewhat by collecting
     entropy of their choice (e.g. from keystroke or mouse timings) and seed-
     ing it into random directly before obtaining important random numbers.
ennuikiller
  • 46,381
  • 14
  • 112
  • 137
  • But lets say you are pulling from random or urandom. and the system is just sitting there on lets say a live cd. Wouldn't the entropy be similar every time the same scenario occurred,. – Recursion Dec 08 '09 at 19:08
  • That's a link to a BSD man page, and in this case the Linux behavior is different: /dev/random is "stronger" than /dev/urandom. – Eric Seppanen Dec 08 '09 at 19:31
1

use /dev/urandom, its cryptographically secure.

good read: http://www.2uo.de/myths-about-urandom/

"If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter."

When in doubt in early boot, wether you have enough entropy gathered. use the system call getrandom() instead. [1] Its best of both worlds, it blocks until (only once!) enough entropy is gathered, after that it will never block again.

[1] git kernel commit

harmv
  • 1,905
  • 22
  • 22