Issue #9569 has been updated by Delan Azabani.


Yui NARUSE wrote:
> getrandom has some limitations like its max output (33554431), and consumes entropy.

This probably won°«t add much to the conversation, but getrandom(2) and /dev/random don°«t °»consume°… entropy any more than /dev/urandom does. getrandom(2) can be told to read from either of the devices. /dev/random and /dev/urandom have separate entropy pools, but they use the same algorithm. The only difference between them is that /dev/urandom doesn°«t block when its °»entropy estimate°… is °»low°… °Ĺ a misleading and simplistic mistake that we°«re now stuck with on Linux. The °»estimate°… would only matter slightly if you°«re in information theoretic territory and you also believe that SHA-1 or the Linux PRNG is broken.

If you don°«t agree, then using /dev/urandom (or anything that°«s based on it) *also* consumes entropy, but now you simply won°«t be told when it°«s too low.

----------------------------------------
Bug #9569: SecureRandom should try /dev/urandom first
https://bugs.ruby-lang.org/issues/9569#change-58828

* Author: Corey Csuhta
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 
----------------------------------------
Right now, `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](http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/)) 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?

Relevant lines: https://github.com/ruby/ruby/blob/trunk/lib/securerandom.rb#L59-L90



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>