SecureRandom should try /dev/urandom first
SecureRandom.random_bytes tries to detect an OpenSSL to use before it tries to detect
/dev/urandom. I think it should be the other way around. In both cases, you just need random bytes to unpack, so SecureRandom could skip the middleman (and second point of failure) and just talk to
/dev/urandom directly if it's available.
Is this a case of just re-ordering the two code chunks so that
/dev/urandom is tried first?
#1 Updated by Akira Tanaka over 1 year ago
- Status changed from Open to Rejected
/dev/urandom is not suitable to be used to generate directly session keys
and other application level random data which is generated frequently.
random(4) on GNU/Linux:
The kernel random-number generator is designed to produce a small amount of high-quality seed material to seed a cryptographic pseudo- random number generator (CPRNG). It is designed for security, not speed, and is poorly suited to generating large amounts of random data. Users should be very economical in the amount of seed material that they read from /dev/urandom (and /dev/random); unnecessarily reading large quantities of data from this device will have a negative impact on other users of the device.
/dev/urandom should be used as "seed" for CPRNG.
OpenSSL do it.
/dev/urandom usage in securerandom.rb is not a good way.
So OpenSSL should be used at first.
#2 Updated by Corey Csuhta over 1 year ago
random(4) manpage on Linux isn't accurate in this reguard. You can use it as more than just a seed source, and you can use it as frequently as you want.
On modern Linux, both
/dev/urandom are CSPRNGs, and can be used safely (after system boot, see references). The only difference is that
/dev/random attempts to keep some kind of measure of its available entropy, and will sometimes block if if feels unsatisfied about that. On FreeBSD, Unix, and OS X, there is no difference between
/dev/urandom anymore, and the manpages on OS X at least don't include this "rate-limit" warning about
Two additional points:
OpenSSL seeds itself from
/dev/urandom as you stated, but you could run a lot of OpenSSL processes on your system at one time and none of them would complain that your
/dev/urandom is not currently to be trusted because you used it too much.
SecureRandom in Ruby will use
/dev/urandom if OpenSSL is not available, based on the code snippet I linked in the original post. This is contrary to your statement that
/dev/urandom is not safe for sessions, or frequent access. As currently implemented,
SecureRandom will access
/dev/urandom frequently if OpenSSL is not available.
#4 Updated by Corey Csuhta over 1 year ago
Akira, can you address this point?
SecureRandom in Ruby will use /dev/urandom if OpenSSL is not available, based on the code snippet I linked in the original post. This is contrary to your statement that /dev/urandom is not safe for sessions, or frequent access. As currently implemented, SecureRandom will access /dev/urandom frequently if OpenSSL is not available.
#5 Updated by Akira Tanaka over 1 year ago
I said "/dev/urandom usage in securerandom.rb is not a good way." already.
It means securerandom.rb will consume too much entoropy if /dev/urandom is used directry.
It is not a big problem because most users use OpenSSL.
Also, we can say "Please install OpenSSL" if someone complain about the entoropy consumption.
Your proposal breaks this strategy.