Issue #9569 has been updated by Shyouhei Urabe.


Yui NARUSE wrote:
> Shyouhei Urabe wrote:
> > @naruse Do you think it's inadequate for Linux users to fall back to getrandom(2)?  If so, why?
> 
> getrandom has some limitations like its max output (33554431), and consumes entropy.

According to getrandom(2) manpage, that 33554431-bytes limitation only applies to 32bit environments.  Why not repeatedly call it again and again to fulfill the needs?  Given 32bit, repetition cannot go any further than 128 times.

My private feeling is it's even worse than current situation to copy & paste arc4random source code.  I don't pretend everything requested in this thread is totally bad.  I especially support the motivation to _write less code_ to maximize security.  Your securerandom.gem seems like replacing one nightmare with another.

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

* 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>